For the size of the icon, we can have something like BS is providing for input or buttons size '.lg' for large or '.sm' for small, like '.icon .icon-search .icon-lg'.
An interesting option would be to have a responsive or adaptable size that takes the size of the container (width: 100%). It could be a solution for the AppBar for example for the icons to change dimension depending on the media query. Thanks, Caty On Thu, Jul 10, 2014 at 3:08 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > Just a note, although 'icon icon-page' might be very semantic as names, > I'm sure .glyphicon and .fa used this naming convention in order not to > conflict with the very generic 'icon' name. We can select something more > particular too. It reduces the semantic meaning, and maybe it will add some > lenght to the class name, but at least we get more error-proof. > > Thanks, > Caty > > > On Thu, Jul 10, 2014 at 2:59 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > >> >> >> >> On Thu, Jul 10, 2014 at 1:25 PM, Guillaume "Louis-Marie" Delhumeau < >> [email protected]> wrote: >> >>> 2014-04-24 22:15 GMT+02:00 [email protected] <[email protected]>: >>> >>> > Yes using font-based icons is interesting (BTW >>> > http://fortawesome.github.io/Font-Awesome/icons/ looks richer than >>> > http://www.entypo.com/ to me). >>> > >>> > However, first we need to decide if we wish to support several icon >>> sets >>> > or only have one that can potentially be configured. >>> > >>> > Supporting several icon sets means means introducing a new syntax in >>> XWiki >>> > Syntax 2.2. For example: >>> > >>> > image:icon:<set name>:<icon name> >>> > >>> > Examples: >>> > * image:icon:silk:accept >>> > * image:icon:fa:home >>> > >>> > Now that makes it harder to reference an icon as it means more typing >>> so >>> > we could also imagine a configurable mapping (defined in >>> xwiki.properties) >>> > as follows: >>> > >>> > <prefix>.icon.mappings = accept = silk:accept >>> > <prefix>.icon.mappings = home = fa:home >>> > >>> > As a user you’d write: >>> > image:icon:accept >>> > image:icon:home >>> > >>> > (technically we’d check the number of “:” after “icon”. If 2 then it’s >>> a >>> > named icon set. If 1 then it’s the default mapping) >>> > >>> > This would have the advantage of allowing mixing icon sets easily >>> without >>> > being verbose and with this we would even be able to rewire icons >>> without >>> > changing page content (for example image:icon:accept could be rewired >>> from >>> > the silk icon set to the fa icon set’s fa:check). >>> > >>> > Now, we could also decide that we don’t introduce the icon set notation >>> > and that we only keep the icon:<icon name> format and that everything >>> has >>> > to go through the configurable mapping. >>> > >>> > Or we could decide that we only ever want one icon set at a time, >>> define >>> > properly all the icon names we wish to have and allow configuring the >>> > mapping of these name to a an icon set. >>> > >>> >>> Or... it could even depends on the skin. Colibri uses silk and Flamingo >>> font-based icons. >>> >> >> IMO this can only be done by using Icon Themes, see >> http://jira.xwiki.org/browse/XWIKI-8501 >> >> We replace everywhere the usage by variables, like '$theme.icon.page' >> .actionmenu .tmPage { >> background-image: $theme.icon.page; >> } >> where >> #set($discard = $themeI.put('icon.page', >> "url($xwiki.getSkinFile('icons/silk/page_white_text.gif'))")) >> etc. >> This is the case when we have images inserted with background-image. >> >> >> In case of font icons, we can have something like >> <div class="icon icon-page"></div> >> >> where if the IconTheme is set to Font Awesome we have >> .icon:extend(.fa all) {} >> .icon-search:extend(.fa-search all) {} >> >> or if the IconTheme is set to Glyphicons we have >> .icon:extend(.glyphicon all) {} >> .icon-search:extend(.glyphicon-search all) {} >> >> We will need to modify some calls and someone needs to investigate a bit >> what we use. >> >> >> Related to icons there are some very old investigations that can be found >> here >> http://design.xwiki.org/xwiki/bin/view/Standards/IconsStudy >> http://platform.xwiki.org/xwiki/bin/view/DevGuide/StandardIconClasses >> http://design.xwiki.org/xwiki/bin/view/Standards/Icons >> >> Thanks, >> Caty >> >> >>> >>> >>> >>> > >>> > WDYT? >>> > >>> > Thanks >>> > -Vincent >>> > >>> > On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected]) wrote: >>> > >>> > +1 for a font-based icon set, but before deciding on a specific one, we >>> > should make sure that we have a replacement for all the icons that >>> we're >>> > currently using. After a very quick look, it doesn't look like the >>> > entypo font covers enough of our needs. Silk doesn't either, to be >>> fair... >>> > >>> > On 04/24/2014 01:03 PM, Yacine Kebir wrote: >>> > > Hello, >>> > > >>> > > i have an idea concerning the icons of base skin colibri or others, >>> we >>> > > should integrate "Entypo" on the skin ans delete all image icons, the >>> > > advantage is : >>> > > 1- we win the chargement time of pages >>> > > 2- reduce the number of code lines in the code. >>> > > 3- we can add, edit , put color and change the sise of this icons >>> > > 4- the skin of this icons are in flat design and we can put it in any >>> > form >>> > > 5- its free for any users >>> > > for more information http://www.entypo.com/ >>> > > wordpress have just integrate this solution >>> > > >>> > > Yacine >>> > _______________________________________________ >>> > devs mailing list >>> > [email protected] >>> > http://lists.xwiki.org/mailman/listinfo/devs >>> > >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
