SQ, > 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
this is good -> embedded > 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 > 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 > Research topics: > - How "CSSImages" (which i am calling this for now) impacts the Image > object's parent object (Atom, Button, etc.) important question > - 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? > - 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 > 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 > 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 > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ 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 qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
