[qooxdoo-devel] Embed design elements rather than use images

Discussion:

SQville

2016-02-26 19:07:17 UTC

Community,

Want to get your general thoughts on something. I have a love-hate
relationship with images. I don't like the fact that image loading is not in
my total control. I have an approach that changes this. I will keep this
short and provide code examples for you to reference and/or step through at
your convenience.

*Goal:* Embed the small decorator images found in resource folders (such as
triangles, checks, dots, lines and boxes) into qx code using qx decoration
entries and/or CSS/CSS3 code.

*Purposes:* 1) reduce number of http calls 2) enhance UX of apps - CSS is
fast and native

*Code:*
See the comments to image references lines - I noted which images i replaced
with code
https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Image.js

Mixin to enable before and after psudo elements and CSS3 functionality
https://github.com/sqville/sqv/blob/master/source/class/sqv/ui/decoration/MCssIcon.js

Appearance entry changes: around lines 1264 and 1308
https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Appearance.js

Decorator entry changes: see line 1901
https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Decoration.js

*In Summary:*
Question: Why? Answer: Why not? :-)

SQ

--
View this message in context: http://qooxdoo.678.n2.nabble.com/Embed-design-elements-rather-than-use-images-tp7588132.html
Sent from the qooxdoo mailing list archive at Nabble.com.

d***@cost-savers.net

2016-02-26 19:59:49 UTC

Permalink

SQ,

The idea is good.
What about presenting a compatibility table too?
Then the question is what browsers and their versions should be compatible else there will be a code overload?
Any impact on speed in any dimension?
Do you have a full testing version?
Do you have any test cases with timers etc?
What else do we need to research here?

Stefan

Post by SQville
Community,
Want to get your general thoughts on something. I have a love-hate
relationship with images. I don't like the fact that image loading is not in
my total control. I have an approach that changes this. I will keep this
short and provide code examples for you to reference and/or step through at
your convenience.
*Goal:* Embed the small decorator images found in resource folders (such as
triangles, checks, dots, lines and boxes) into qx code using qx decoration
entries and/or CSS/CSS3 code.
*Purposes:* 1) reduce number of http calls 2) enhance UX of apps - CSS is
fast and native
*Code:*
See the comments to image references lines - I noted which images i replaced
with code
https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Image.js
Mixin to enable before and after psudo elements and CSS3 functionality
https://github.com/sqville/sqv/blob/master/source/class/sqv/ui/decoration/MCssIcon.js
Appearance entry changes: around lines 1264 and 1308
https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Appearance.js
Decorator entry changes: see line 1901
https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Decoration.js
*In Summary:*
Question: Why? Answer: Why not? :-)
SQ
--
View this message in context: http://qooxdoo.678.n2.nabble.com/Embed-design-elements-rather-than-use-images-tp7588132.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

SQville

2016-02-27 15:33:15 UTC

Permalink

Excellent thoughts Stefan!

My quick thoughts on your questions (please point out holes in my logic
where you see them):

Take the list of images in this file
(https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Image.js)
as the official list of images that I am going to convert to code. Now i
will break down the list by approach:

1) 5% of images can be converted to standard qx decorator entries (Low
impact on performance; Standard qx functionality; *"Very Safe"*). Standard
qx testing approaches apply.
An example is a simple box. A simple box can be rendered by setting border
values
2) The rest of the images will need psudo elements (after and before) to
render and will use standard CSS functionality (no CSS3). Addition of the
CSS elements and rules will use qx's existing approach and cross browser
checks (i.e. qx.core.Environment). Medium impact on performance; Uses
prescribed qx functionality; Increases overall file size; *"Safe" (in my
opinion)*
3) Mix of #1, #2 + CSS3 - Since CSS3 is in the mix, here is where your full
list of thoughts apply. Low to High impact on performance. Larger file size
if heavy CSS3 animation is utilized. Broad browser coverage enabled by
qx.core.Environment checks. Browser compatibility limited by browser's CSS3
handling capabilities.

Research topics:
- How "CSSImages" (which i am calling this for now) impacts the Image
object's parent object (Atom, Button, etc.)
- These new "CSSImages" become small little islands of CSS code,
unreachable by theme code - Is this proper?
- Can this be better handled using an external .css file referenced in the
app's config.json file (i.e. like qx.Mobile css handling using getCssClass()
function within Application code)?

We've reached the end of my work here. Any thoughts beyond this point is new
territory :-)

SQ

--
View this message in context: http://qooxdoo.678.n2.nabble.com/Embed-design-elements-rather-than-use-images-tp7588132p7588135.html
Sent from the qooxdoo mailing list archive at Nabble.com.

d***@cost-savers.net

2016-02-27 17:55:42 UTC

Permalink

SQ,

Post by SQville
Excellent thoughts Stefan!
My quick thoughts on your questions (please point out holes in my logic
Take the list of images in this file
(https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Image.js)
as the official list of images that I am going to convert to code. Now i
1) 5% of images can be converted to standard qx decorator entries (Low
impact on performance; Standard qx functionality; *"Very Safe"*). Standard
qx testing approaches apply.
An example is a simple box. A simple box can be rendered by setting border
values

this is good -> embedded

Post by SQville
2) The rest of the images will need psudo elements (after and before) to
render and will use standard CSS functionality (no CSS3). Addition of the
CSS elements and rules will use qx's existing approach and cross browser
checks (i.e. qx.core.Environment). Medium impact on performance; Uses
prescribed qx functionality; Increases overall file size; *"Safe" (in my
opinion)*

it is ok too -> embedded

Post by SQville
3) Mix of #1, #2 + CSS3 - Since CSS3 is in the mix, here is where your full
list of thoughts apply. Low to High impact on performance. Larger file size
if heavy CSS3 animation is utilized. Broad browser coverage enabled by
qx.core.Environment checks. Browser compatibility limited by browser's CSS3
handling capabilities.

must be measured -> compare standard qooxdoo with the same number of classes with a forked and changed qooxdoo

Post by SQville
- How "CSSImages" (which i am calling this for now) impacts the Image
object's parent object (Atom, Button, etc.)

important question

Post by SQville
- These new "CSSImages" become small little islands of CSS code,
unreachable by theme code - Is this proper?

rather...
can themes still be developed...?
does it break the existing theme chain and how exactly?

Post by SQville
- Can this be better handled using an external .css file referenced in the
app's config.json file (i.e. like qx.Mobile css handling using getCssClass()
function within Application code)?

outside -> not embedded ...I don't like this approach! ...by the way you step out of your initial bothering of massive load of images instead of local rendering

Post by SQville
We've reached the end of my work here. Any thoughts beyond this point is new
territory :-)

The best way to test the idea and measure it is to...
- fork qooxdoo
- make changes -> local rendering
- measure and compare standard qooxdoo with forked one

What does the rest of the community say?
Is this something we should put energy into?
In case of a positive answer from community...are you SQ ready to make a test fork?

Stefan

Post by SQville
SQ
--
View this message in context: http://qooxdoo.678.n2.nabble.com/Embed-design-elements-rather-than-use-images-tp7588132p7588135.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

d***@cost-savers.net

2016-02-27 18:15:53 UTC

Permalink

one important thing here...

the benefit of local rendering is support of accessibility - making your GUI usable by people with disabilities

This is a very important improvement!

Many users, even those not visually impaired, benefit from magnification of text and graphics. However, without magnification, a visually impaired user may not be able to access and use the program at all.

- Provide the ability for the user to magnify the work area.
- Provide options in the application to scale the work area. Users need to have an option to magnify the work area 150% to 400% or more. Test the application to confirm the object you are viewing is not affected by changing the magnification settings.

...amongst others..

Source: https://developer.gnome.org/accessibility-devel-guide/stable/gad-ui-guidelines.html.en

Stefan

John Spackman

2016-02-27 22:48:54 UTC

Permalink

Have you looked at combining multiple images into one? This would allow a
similar drastic reduction in resource requests. There are features in
qooxdoo to support this - although it's been a while since I've looked at
it so while there may well be ways support for this can improve.

However I do like the CSS approach, and can see that there would be plenty
of occasions where CSS is more appropriate (or useful) than images. From
reading your code, this is something that works quite happily without
changes to Qooxdoo itself? And so therefore the changes to Qooxdoo would
be just to implement the icons as CSS, provided that the new decorator was
available, which would amount to a new theme?

In which case it sounds like something that would be fairly easy to test
and evaluate as integration into one or more themes; as Stefan suggests,
please can you create a fork with a branch so that we can try it out?

Regards
John

----------------------------------------
From: ***@cost-savers.net
Sent: Saturday, February 27, 2016 6:28 PM
To: qooxdoo-***@lists.sourceforge.net
Subject: Re: [qooxdoo-devel] Embed design elements rather than use images

one important thing here...

the benefit of local rendering is support of accessibility - making your
GUI usable by people with disabilities

This is a very important improvement!

Many users, even those not visually impaired, benefit from magnification of
text and graphics. However, without magnification, a visually impaired user
may not be able to access and use the program at all.

- Provide the ability for the user to magnify the work area.
- Provide options in the application to scale the work area. Users need to
have an option to magnify the work area 150% to 400% or more. Test the
application to confirm the object you are viewing is not affected by
changing the magnification settings.

...amongst others..

Source:
https://developer.gnome.org/accessibility-devel-guide/stable/gad-ui-guidelin
es.html.en

Stefan

----------------------------------------------------------------------------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

Dietrich Streifert

2016-02-29 11:51:04 UTC

Permalink

Hi SQ, (Chris?),

very interesting approach to use css for creating the icon images. I
think this is meant to be used for icons in standard buttons e.g. radio
button and check box?

I have some qooxdoo apps which have forms with really (I mean really!) a
lot of radio buttons and check boxes which also "suffer" from the "bold"
implementation of the standard buttons in the current version.

What I tried to do is to pre load all images / accompanied with cache
settings for the corresponding http request answers from the web server
(apache), so that on button creation or state change images are loaded
from browser cache. This reduced tremendous the server requests related
to images.

Just want to mention another potential possibility which I implemented
for radio buttons and check boxes:

In the current implementation buttons derive from atom, which uses three
div elements to render the button. I've did an alternative
implementation which only uses one div, using css background image,
margin and padding manipulations to render the button icon. The
implementation is currently incomplete, as it only supports the icon
being placed on the left side of the button. I would name it "a hack".

This helped a lot reducing the time for the first rendering of the
complex form, especially because of the reduced div elements needed, the
biggest gain on internet explorer.

It would be very interesting to see if the "reduced number of div"
implementation is somehow combinable with your idea, What would mean
that we must be able to restrict the CSS rendering to the appropriate
button side.

Another idea I had is to use pseudo elements :after and :before and to
use herein (though I don't know currently if this is possible) web icon
fonts where the icon font character is determined by the content css
attribute, which also would reduce the number of requests as the font is
loaded only once, containing all needed button state icons.

Regards
Dietrich

Tobias Oetiker

2016-02-29 12:48:30 UTC

Permalink

Dietrich,

Post by Dietrich Streifert
Hi SQ, (Chris?),
very interesting approach to use css for creating the icon images. I
think this is meant to be used for icons in standard buttons e.g. radio
button and check box?
I have some qooxdoo apps which have forms with really (I mean really!) a
lot of radio buttons and check boxes which also "suffer" from the "bold"
implementation of the standard buttons in the current version.
What I tried to do is to pre load all images / accompanied with cache
settings for the corresponding http request answers from the web server
(apache), so that on button creation or state change images are loaded
from browser cache. This reduced tremendous the server requests related
to images.
Just want to mention another potential possibility which I implemented
In the current implementation buttons derive from atom, which uses three
div elements to render the button. I've did an alternative
implementation which only uses one div, using css background image,
margin and padding manipulations to render the button icon. The
implementation is currently incomplete, as it only supports the icon
being placed on the left side of the button. I would name it "a hack".
This helped a lot reducing the time for the first rendering of the
complex form, especially because of the reduced div elements needed, the
biggest gain on internet explorer.
It would be very interesting to see if the "reduced number of div"
implementation is somehow combinable with your idea, What would mean
that we must be able to restrict the CSS rendering to the appropriate
button side.
Another idea I had is to use pseudo elements :after and :before and to
use herein (though I don't know currently if this is possible) web icon
fonts where the icon font character is determined by the content css
attribute, which also would reduce the number of requests as the font is
loaded only once, containing all needed button state icons.

not sure I followed all the arguments properly ... but what is the
problem of using https://en.wikipedia.org/wiki/Data_URI_scheme to
minimize calls ? coupled with the css background image aproach this
should be pretty 'lite' I think ...

cheers
tobi

Post by Dietrich Streifert
Regards
Dietrich

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch ***@oetiker.ch +41 62 775 9902

Dietrich Streifert

2016-02-29 13:23:45 UTC

Permalink

Hi Tobi,

That would be another option, that's right.

But what about sharing the uri between widget instances? I suppose we
then have to use css classes with apropriate data uri defined for each
state?

But my message was not only about call minimization, but also related to
dom element minimization.

Regards
Dietrich

Post by Tobias Oetiker
Dietrich,
not sure I followed all the arguments properly ... but what is the
problem of using https://en.wikipedia.org/wiki/Data_URI_scheme to
minimize calls ? coupled with the css background image aproach this
should be pretty 'lite' I think ...
cheers
tobi

Adrian Haarbach

2016-02-29 13:37:26 UTC

Permalink

Hi all,

Web icon fonts seem to be the new trend (nice article:
http://alistapart.com/article/the-era-of-symbol-fonts) regarding further
optimization of image loading performance and also image quality (i.e.
vector vs raster images), especially needed for the higher (retina, 4k)
screen resolutions of today's desktop hardware.

This is why I really like Dietrichs' last idea of using web icon fonts:

Another idea I had is to use pseudo elements :after and :before and to

Post by Dietrich Streifert
use herein (though I don't know currently if this is possible) web icon
fonts where the icon font character is determined by the content css
attribute, which also would reduce the number of requests as the font is
loaded only once, containing all needed button state icons.

I think SQ had a similar idea in the thread named:
[qooxdoo-devel] FontAwesome font icons for qx.Desktop.

Once I am able to patch qx.basic.Image to use symbol fonts rather than
(png) images, I will post my results on the other thread!

Adrian

2016-02-29 14:23 GMT+01:00 Dietrich Streifert <

Post by Dietrich Streifert
Hi Tobi,
That would be another option, that's right.
But what about sharing the uri between widget instances? I suppose we
then have to use css classes with apropriate data uri defined for each
state?
But my message was not only about call minimization, but also related to
dom element minimization.
Regards
Dietrich

Dietrich Streifert

2016-02-29 14:35:34 UTC

Permalink

Hi Adrian,

I'll go for the future definitely with icon fonts regarding the
"standard" buttons like check box and radio box, maybe with additional
css to style focus states etc. For colourful icons I'll maybe use svg in
conjunction with the data uri.

For the theme (aristo) I'm using, I will loose the fat/3d button look
and will replace it via a flat material design oriented look for the
check box and radio box buttons.

Still I'll have to wait a bit until IE8/9 really dies, as I have very
conservative customers, because all this will not work in IE8/9 (I think).

But what I also want to bring up again is the reduction of the check box
and radio box widgets from now 3 dom elements (based on atom) to a new
layout only using one dom element or one dom element and one pseudo
element. But this change may break compatibility with the current
implementation.

Regards
Dietrich

Post by Adrian Haarbach
Hi all,
http://alistapart.com/article/the-era-of-symbol-fonts) regarding
further optimization of image loading performance and also image
quality (i.e. vector vs raster images), especially needed for the
higher (retina, 4k) screen resolutions of today's desktop hardware.
Another idea I had is to use pseudo elements :after and :before and to
use herein (though I don't know currently if this is possible) web icon
fonts where the icon font character is determined by the content css
attribute, which also would reduce the number of requests as the font is
loaded only once, containing all needed button state icons.
[qooxdoo-devel] FontAwesome font icons for qx.Desktop.
Once I am able to patch qx.basic.Image to use symbol fonts rather than
(png) images, I will post my results on the other thread!
Adrian

Dietrich Streifert

2016-02-29 16:59:57 UTC

Permalink

Here is a short fiddle:

https://jsfiddle.net/7yfb7suL/

Post by Dietrich Streifert
Hi Adrian,
I'll go for the future definitely with icon fonts regarding the
"standard" buttons like check box and radio box, maybe with additional
css to style focus states etc. For colourful icons I'll maybe use svg
in conjunction with the data uri.
For the theme (aristo) I'm using, I will loose the fat/3d button look
and will replace it via a flat material design oriented look for the
check box and radio box buttons.
Still I'll have to wait a bit until IE8/9 really dies, as I have very
conservative customers, because all this will not work in IE8/9 (I think).
But what I also want to bring up again is the reduction of the check
box and radio box widgets from now 3 dom elements (based on atom) to a
new layout only using one dom element or one dom element and one
pseudo element. But this change may break compatibility with the
current implementation.
Regards
Dietrich

SQville

2016-03-01 00:13:54 UTC

Permalink

Great discussions/comments/advice... thank you all!

*My take-away's from this thread so far:*

Images, CSS(3), fonts are core to the web itself. We need *solid* options
(solid = well documented, non-hack, identified ownership if not part of
core) for ways of utilizing these fundamental design elements in our
qx.desktop apps.

All solutions offered here were good solutions to my problem (Data uri's,
consolidated and cached images, font icons, etc.) - thank you!

We need to revisit/establish design principles/framework to help us navigate
these types of waters. I will do my best to contribute to this effort.

Thanks

Chris

--
View this message in context: http://qooxdoo.678.n2.nabble.com/Embed-design-elements-rather-than-use-images-tp7588132p7588153.html
Sent from the qooxdoo mailing list archive at Nabble.com.

Tobias Oetiker

2016-02-29 14:06:36 UTC

Permalink

Hi Dietrich,

in order to NOT have to copy the same DATA uri multiple times, you
could setup a css rule on the fly with the name of the embedded
image and then assign the class to the div in order to have to only
embedd the data uri once ...

but I agree with the other poster that icon fonts are much cooler
if the design does not call for icons rgb colors ...

Post by Dietrich Streifert
But my message was not only about call minimization, but also related to
dom element minimization.

yes ...

cheers
tobi

Post by Dietrich Streifert
Regards
Dietrich

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch ***@oetiker.ch +41 62 775 9902