Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Jon Robson wrote:
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file.
I hope that the template can be customizable. The skin I've coded involves moving elements (lists) around and re-grouping them, and assigning new classes to some of them.
Jon Robson wrote:
- Should be possible for us in future to re-render an entire page via
JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
I hope that non-JS folks stay in the working area. ;-)
Thanks for the update.
svetlana
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 jrobson@wikimedia.org wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Aug 26, 2014 at 6:21 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
It would be trivially simple to add twig (or any other Composer managed templating library) to mediawiki/vendor.git following the process outlined in the recently accepted Composer managed libraries RFC [0].
[0]: https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_librari...
Someone in one of our meetings mentioned that Twig 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 tparscal@wikimedia.org wrote:
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 jrobson@wikimedia.org wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Someone in the meeting also claimed that Swig and Twig were compatible, and that does appear to be generally true, but I think there are some deviations.
- Trevor
On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
Someone in one of our meetings mentioned that Twig 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 tparscal@wikimedia.org wrote:
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 jrobson@wikimedia.org
wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days.
On Wed, Aug 27, 2014 at 2:26 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Someone in the meeting also claimed that Swig and Twig were compatible, and that does appear to be generally true, but I think there are some deviations.
- Trevor
On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
Someone in one of our meetings mentioned that Twig 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 tparscal@wikimedia.org wrote:
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 jrobson@wikimedia.org
wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
As next steps we agreed to do the following:
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 08/27/2014 05:51 PM, Monte Hurd wrote:
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days.
Is this just a temporary solution since the SVGs for some fonts have been lost?
If not, why do we need a font->SVG workflow? My understanding is that SVG is always the source code, even for WikiFont (which generates font file output from SVG source code).
Matt Flaschen
It came out in a meeting about icons, that a major impetus of Wikifont was the workflow for designers being easier if all icons are sourced from a single font file, and not individual SVG files. The SVG-to-font workflow is helpful for the iOS app which uses the font (apparently the Android app does not). The font-to-SVG workflow was an idea to try and make it possible for designers to use their "font is the source" workflow.
I personally believe that being a designer at Wikimedia should mean working with open formats (SVG, CSS, HTML), checking assets into git repositories, and seeking to make community contribution easier, not more difficult. The idea that a font file, which is a big blob of binary data, be the official source of all icons just doesn't scale, and makes contribution much more difficult.
In the meeting we seemed to agree that it was worth developing further the tools to have more features and an easier workflow when working with SVG (with PNG fallbacks). Work is already underway to achieve this, and I am looking forward to us having an easy to use, easy to contribute to and well performing system for designing, refining and delivering icons.
- Trevor
On Wed, Sep 3, 2014 at 6:43 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/27/2014 05:51 PM, Monte Hurd wrote:
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days.
Is this just a temporary solution since the SVGs for some fonts have been lost?
If not, why do we need a font->SVG workflow? My understanding is that SVG is always the source code, even for WikiFont (which generates font file output from SVG source code).
Matt Flaschen
On Sep 3, 2014, at 8:46 PM, Trevor Parscal tparscal@wikimedia.org wrote:
The font-to-SVG workflow was an idea to try and make it possible for designers to use their "font is the source" workflow.
Not quite. The point of the conversion scripts (which are done and seem to work pretty well) is to make it possible for designers (and me) to use a "svg is the source" workflow and pipe these svgs through the scripts if we happen to need a font representation.
On Sep 3, 2014, at 6:43 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
WikiFont (which generates font file output from SVG source code).
tl:dr SVGs yay!
The problem was WikiFont did not generate itself (magic?) from svgs. The svgs had to be fairly painstakingly imported into a font forge project which was then used to generate the font.
The font forge importation workflow was sticky enough (importing svgs and mapping them, etc) that small visual tweaks (baseline offsets and such) ended up being made in the font forge project itself as well, thus diverging from the source svgs.
I think this workflow stickiness was what led the designer to see the font forge project as canonical.
So... the 2 scripts I wrote.
One automates creating a font from a folder of svgs. Svgs are canonical as they should be, but hey, you want a font? You got it.
The second script, just for fun, reverses the process and creates a folder of svgs from the font.
I've been dogfooding these for the last week for a supplemental font the iOS app uses.
I'll post them hopefully next week when I get a chance to document them. If you can't wait and are in the SF office stop by my desk and I can demo it in about 2 minutes.
On 09/04/2014 03:29 AM, Monte Hurd wrote:
The font forge importation workflow was sticky enough (importing svgs and mapping them, etc) that small visual tweaks (baseline offsets and such) ended up being made in the font forge project itself as well, thus diverging from the source svgs.
This is why automation and having a clear understanding of what the source code is are both so important.
I think this workflow stickiness was what led the designer to see the font forge project as canonical.
Actually, it was somewhat ambiguous what the source code is. Read https://gerrit.wikimedia.org/r/#/c/137888/ if you want to know what I mean.
One automates creating a font from a folder of svgs. Svgs are canonical as they should be, but hey, you want a font? You got it.
Great. This will be useful for the app, and if we ever decide to revisit the decision about icons on web (I completely agree SVG is better as source code, but we could still use generated fonts on desktop if we decided that approach was suitable).
Matt Flaschen
On 26/08/14 22:53, Jon Robson wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not.
We identified the new skin system will have two long term goals:
- We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing)
One of the most powerful features of skins currently is their flexibility, at least until you hit a wall. Aside from the wall bit, that's something to keep around and improve. Such as by taking that wall and shoving... er... nevermind.
Point is, skin creation can't be dumbed down too much. At some point, skin developers will still need to mess with the extension aspects of the skins, they'll need to put things in weird order and extend the objects that wind up building the overall skin, they will need to write complex css/less, and they will need to create their own js or whatever for the skin's specific functions. Limiting how much of that is needed especially for basic stuff should be the goal here, but no platform could ever handle all the different possibilities, so you also need to avoid blocking them in the process.
So, uh, what you're doing sounds good so far, just please be careful or something.
Also, dammit, does anyone know how to make thunderbird send responses back to specific lists when something was sent to multiple? I'd really rather be responding on wikitech-l at this point.
-I
Jon Robson wrote:
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Could someone please review the RfC for accuracy? Is the information up-to-date? I'd like to translate it to other languages to get international feedback, but I was told that the RfC may need a review by a pair of critical eyes first.
svetlana
- Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September.
- We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements.
Hey Trevor Are you able to update us on the current status of the above? Have you begun work on them? Are there any patches you can point at us (even if they are work in progress patches?)