A couple of questions: How expensive is generating and applying CSS on the client?
How do developers that use CSS regularly feel about having to declare that many styles for all the buttons? Maybe tools like Dreamweaver make it simpler and we just need IDEs that could provide assistance. Peter On Nov 7, 2017, at 6:24 AM, Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>> wrote: Some food for thought: I created a custom component for “buttons” which allow simple skinning using image files. It works like this: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tkoafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tkoafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0> Specifying different states can be done using the following css: .bug { background-image: url ('assets/up/report-bug.png'); } .bug:hover{ background-image: url ('assets/over/report-bug.png'); } .bug:active{ background-image: url ('assets/down/report-bug.png'); } .bug:disabled{ background-image: url ('assets/disabled/report-bug.png'); } It works well, but the problem with this approach is that it requires multiple css entries for every button. Using it is done like this: <comp:PanelButton id="bugButton" enabled="{bugReportEnabled}" width="72" height="82" x="19" y="283" click="reportBug()" className="bug"/> I wanted to allow the following: <comp:PanelButton id="bugButton" enabled="{bugReportEnabled}" width="72" height="82" x="19" y="283" click="reportBug()" className="bug" image="assets/up/report-bug.png" hoverImage="assets/over/report-bug.png" activeImage="assets/down/report-bug.png" disabledImage="assets/disabled/report-bug.png"/> However, this is harder than you’d expect in HTML. Apparently there’s no way to set pseudo-styles using inline css.[1][2]. There are a couple of interesting work-arounds. One is using mouse events.[3] Another is by creating CSS on the fly.[4] The answer assumes that the css is created on the server, but using the ideas I proposed in the ThemeManager class, that can be done on the client dynamically. The challenge with the last approach would be in guaranteeing the css is unique to the images (or individual component). One option on that front would be to generate UIDs when the component is instantiated. A consideration is garbage-collecting CSS selectors when components might be removed. I hope these ideas are helpful. Harbs [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nqALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nqALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-pseudo-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaXW6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-pseudo-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaXW6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0> [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&reserved=0> [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&reserved=0> On Nov 6, 2017, at 8:22 PM, Carlos Rovira <carlosrov...@apache.org<mailto:carlosrov...@apache.org>> wrote: Hi Harbs, If we go with Basic as seems everybody suggest, I think we should not mix with Express. We can "copy" some Express knowledge, but not make it dependent, to avoid having a Frankenstein Basic is the core, and from there we have Express and the new stylizable set 2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com<mailto:piotrzarzyck...@gmail.com>>: I was thinking about that and new component set is the approach which we should try, but we need to base on something. My first thoughts was that it should be Basic, cause I bet that once we start create style for each component we will end up with some issue or we would like to create some additional features to those controls in order to make that theme happen. It leads my thought then farther let's say that we will start work in following way: 1) Basic is our base 2) Carlos will prepare some appearance for component 3) We are starting to work on that, but it's end up that our component need some additional feature, which is do not suits for Basic 4) We are adds that feature to Express and use in that place Express component. It ends up that our component theme will be mix of Express and Basic Second approach is - Forget about Express, use Basic only and add to Theme set features if needed. Express will be always separate set, FAT and it will be responsibility for user if he would like to style it. - If our implementation will be in Theme enough robust, user should be able to use in his application Express with some styles from Theme set. Thoughts ? Piotr 2017-11-05 11:21 GMT+01:00 Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>>: I would suggest starting a new component set with a fresh slate called Themed (or something like that). The Themed component set should give priority to style-ablitity and ease of use over just about every other consideration. I think of Express as more of a middle-of the road approach to make things easier. A Themed set would be more of a replacement for mx and spark. Yes. Definitely make a clear list of supported components. It’s probably more important to have quality of components rather than quantity. A few well constructed components is better than a lot of half-baked ones. More components could always be added. I’m very glad to hear that Angelo is working with you. That’s great news! Harbs On Nov 5, 2017, at 12:12 PM, Carlos Rovira < carlos.rov...@codeoscopic.com<mailto:carlos.rov...@codeoscopic.com>> wrote: ok Alex, so if I understand correctly, you mean that we create our own set, with Basic as base right? but we should go with Express? It's great that we could create many sets in Royale, and I think the Basic use you commented is very licit and didn't think about that. But we must think in some *main* set, maybe is Express and that I want to focus this effort for that concrete set. I mean, one important thing here is that we all agree in support a concrete list of UI controls and components I plan to make a discuss thread for this, since the theme feature will affect only to that controls, and if we want to include a new one we should vote to include it, since it implies to include in design, implementation and all themes that we want to support. I think I'll create a discuss thread with this an other things we talked about since this is a huge effort and is important for all the people that will be involved to work around things discussed, voted and approved by all. We need to be synced here or we'll end working too much for somehitng that does not get to be useful in the end. I want to ensure this before to start investing a huge amount of time. As well I was contacted by Angelo and talk about all this. He's very passionate as well on this and we'll seeing how we can combine our efforts and if someone more wants to join us. I'll be writing the discussion thread in order to plan the effort in short. Stay tuned :) 2017-11-05 8:29 GMT+01:00 Alex Harui <aha...@adobe.com.invalid<mailto:aha...@adobe.com.invalid>>: Hi Carlos, I think we're pretty much in agreement. Regarding Basic, for me, I have created plenty of web pages with non-styleable checkboxes. I don't care that the checkbox looks different on different browsers. I just want the smallest simplest output. Just like taking an HTML editor and slapping in a few tags and calling it done. Would that be production? Sure, if I'm just want someone to check a box before enabling a download button. IOW, it would be for internal customers only. So, IMO, a Skinnable/Themeable component set would be something else. I think you will need that extra Span for a Checkbox. IMO, we should just go and build these new components. And when we get it mostly working, we can compare against Basic and see if we want to parameterize the views in the low-level Basic components or not. My 2 cents, -Alex On 11/4/17, 8:19 AM, "carlos.rov...@gmail.com<mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira" <carlos.rov...@gmail.com<mailto:carlos.rov...@gmail.com> on behalf of carlosrov...@apache.org<mailto:carlosrov...@apache.org>> wrote: HI Alex, 2017-11-03 17:52 GMT+01:00 Alex Harui <aha...@adobe.com.invalid<mailto:aha...@adobe.com.invalid>>: Hi Carlos, I skimmed through https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fmaterial .io%2Fguidelines%2F%23&data=02%7C01%7C% 7Cbb03216ec0b84fcb6ab108d52397 82e0 %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% 7C636454056000808812&sdata=g5 M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last night. My impression is that there were two parts to it. First was the environment/principles section which talked about physical objects and light (and motion), and then there were choices of widgets. For example, I didn't see anything in the first part that said that a text input had to be a single line and couldn't be a box. Material guidelines could be a great way to start, but trying to give something different. I think that we need to get something that looks great while be clearly different to google material, bootstrap, and others so people could see us as an alternative. That could make people copying us or adopting the whole Apache Royale SDK that is what we want in the end That made me think that we could use our widget set and apply Material environment and principles to it. If we decide not to, I would think you would want to have some sort of similar environment/principles document which seems like a fair amount of work. I think we'd end up looking different because we have different widgets and maybe some different colors. I'm pretty sure that we don't want to be different so much that we don't create things that folks want to use. The priority to me is just to prove that you can alter every pixel in every widget we have so that others can provide custom skins as well. So starting with Material principles seems like it would save us time, we can get something released, and can innovate more later. I think as you that we need a way to make the "presentation" of each component highly customizable. And we need to be different in visualization (art, colors, ...) but not in usability that is what people needs to be consistently Maybe a good question for our users is: How many of you used the default Flex skins vs a whole new set of skins? If most folks completely re-skinned to match their corporate branding, it matters less what our default is, and more that we can allow folks to customize every pixel. We need both: a skin that will be highly customizable and to change skins to look very very different. People with lees money or time in their Apps will choose the first. People that has more resources will go with the second. Apache Royale needs to support both The wireframe can be black and white, IMO. I was thinking that "vivid" would have parameterized colors. I started to think that wireframe could end having lots of customization controls. For example: -2-3 main colors as we talked , and the same MDL does -possibilitiy to be solid colors, or gradients -possibility to have backgrounds more or less opaque if we see a concrete component like button: - configurable corners, square to round corners - more blocky (relief) or more flat ... So wireframe could be a concrete configuration of the main theme Since Bootstrap was mentioned, I want to point out that the Flat.swc is a rough approximation of the Flat theme which is a Bootstrap theme. It is a rough approximation because I could not use the Flat CSS file directly since it contains much more advanced CSS than we currently support on the SWF side. But it presumed that the Checkbox was a Label with a Span that hides in front of or behind the <input type="check" /> in order to allow customizing every pixel. Looks like MDL uses the same Span trick but maybe without a symbol font. Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox should not have that extra Span. But it looks to me that a SkinnableCheckbox can add that extra Span and you either give it the same class name that BootStrap or MDL uses or create our own set of classnames and the CSS that goes with it. The problem with Basic could be that if is very very basic and looks with a very basic look (as it is very poorly stylizable), I think People will not use it at all, in this case, I'll don't understand the goal with basic. It's intend ended as a base but to not use in production? For this reason is what I want to know if you think this theme feature could be plugged in basic or not. Of course, I could be wrong. This is not my area of expertise at all. Hi Alex, maybe UX is not your expertise area, but your help here is very needed since we can get to great ideas in this field, but maybe don't know how to bring it to implementation in Apache Royale. I think that you, Peter, Harbs,... are needed in order to make this happen in the pure arquitecture side or this feature. Thanks -Alex On 11/3/17, 1:35 AM, "carlos.rov...@gmail.com<mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira" <carlos.rov...@gmail.com<mailto:carlos.rov...@gmail.com> on behalf of carlos.rov...@codeoscopic.com<mailto:carlos.rov...@codeoscopic.com> wrote: Hi Alex, 2017-11-03 7:39 GMT+01:00 Alex Harui <aha...@adobe.com.invalid<mailto:aha...@adobe.com.invalid>>: Hi Carlos, Looks good to me. Thanks for doing this. Thanks :) I'm not sure I understand all of the aspects of this effort. My current understanding is that Google Material is under the Apache License and thus we can use it if we want to. Am I correct that MaterialDesignLite is one implementation of Google Material and we could create our own implementation and it could be visually different? We can implement our own material in Royale, but I'm afraid that doing that will not make us highlight our solution against the rest of competitors. Another point is something I said various times: When I did MDL, I notice a huge problem: MDL has its own set of components, some are in all sets (Button) but others not (Card), and they has it's own implementation, what make it almost impossible generalize a theme. For this reason I always point that we need our own set and there we can implement themes. But other *externa* sets will never get this since they have its own implementation and most important once you start to develop with MDL you can't go back and change for other. So MDL is for me something we have until our own set are robust and highly configurable in both the things we can do and how can it could be represented, and switch between style should be really easy to change the global look of an App without much hassle. Also, IIRC, Material has different components than Flex did so we'd have to invent some new looks anyway. So having a TextInput with borders all around would just be our flavor of Material. That's what I point above. We must to *freeze* the list of components at some time work over a concrete set We can then plan in the future include a new component in the official set, and that will need to work on the themes we already have to include the new one. Regarding colors, it looks like Material is parameterized around a couple of colors. So if we did our skins to work against parameterized colors then would it really matter what color we choose? That's completly right. I could make wireframe based on two or three colors and as you change it in CSS all controls should tint consistently. Regarding Basic components, right now Checkbox is a <label><input type="check"/>caption</label>. AIUI, you cannot style the <input> on many browsers, so I think we have to have a different set of elements in a checkbox. It looks like Bootstrap uses: <label><input type="check"/><span />Caption</label> Where the span uses a special symbol font with checked and unchecked boxes. That's what we need to figure. Should we make themes available in Basic? if so, has basic the right implementation? If not, and if we don't want to change the actual very basic implementation, we need to put some "skin" implementation that at least in JS implementation I figure that will change one face (the actual basic) with the theme face. I'm thinking loud, since this is something we should explorer all together mixing the best ideas of people involved Thanks Thanks, Alex On 11/2/17, 5:15 PM, "carlos.rov...@gmail.com<mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira" <carlos.rov...@gmail.com<mailto:carlos.rov...@gmail.com> on behalf of carlosrov...@apache.org<mailto:carlosrov...@apache.org>> wrote: Hi, I want to expose my initial work (very very initial) on two styles for Royale Wireframe: https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fsnag.gy%2 FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 0f48%7Cfa7b1b5a7 b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& sdata=%2Fk8YQxC5bDOaC D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0 (Wireframe intention is for quick Royale App prototyping, people will use this to start their applications, and then moving to it's own styling that could be another royale theme provided by us, or something done by users. Vivid (to put some temporal name): https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fsnag.gy%2 FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 0f48%7Cfa7b1b5a7 b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& sdata=kxYE7ylOsXPUEeE r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0 (*Please, Notice that only the first button has some styling here*) (This theme could be the default theme for royale components like halo was for mx and spark was for spark) I want to put in place all the main components, so I would need some "component list" (Button, TextInput, CheckBox,...and what more?.), and we'll be centering all the effort in only that list of components. We need to "paint" all and the code all. The concept of theme involve a concrete set of components (and this bring us again if we should do this to be pluggable for Basic, or go directly with Express, I think even Basic should be able to use a theme maybe using beads to be PAYG) So, before continue tomorrow, I want some feedback on this: * I think Wireframe is clearly something Black&White, maybe as I did, in some grey scale colors. But for Vivid, I'm still figuring if it should be something "flat" and very simple, or go with something more elaborated since the thing I did in the example with orange button. * I like the look and feel of Google Material, how textfields looks and behaves, the animations, and visual concepts. But the problem is that all that visuals are clearly Google Material. Should we create something more new? This has a problem that maybe we could reach something great....or not, and is more work to iterate something until we reach a good point. For example, the text input I created has the classic box look, for me Material Design is better with only a bootom line, but the first is more generalist, while the second is clearly google, android,... I could try to think in something new a see what happens * In the other hand, someone would want to join me in this effort? If so I could center in the design part, and other person could work with me on the example project "RoyaleThemes". The example app is very important, since it could have a playground for every component so we can tweak at runtime. we could even generate the code to get that look...this could be like FlexThemeManager App that we had in the Flex days. * About colors for the second again, don't have any preferences right now, I put the same colors that use on the web in the first button, but as I said before things (colors and forms) could change dramatically in the second set. In the first one (Wireframe) I think it's ok to go the path exposed in the image example. Thanks for your comments on this, we'll be defining what we want as we comment here ok? I'm done for today, 2017-11-02 14:22 GMT+01:00 Carlos Rovira < carlosrov...@apache.org<mailto:carlosrov...@apache.org> : Thanks Harbs! very useful, I'll be keeping this info as I make some work Carlos 2017-11-02 12:13 GMT+01:00 Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>>: BTW, the kind of thing we should be striving for in theme-able components is something like this: https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fvcalend ar.netlify.com<http://ar.netlify.com>%2F&data=02%7C01%7C% 7C203485b5b9c744aed92608d52250 0f48%7Cf a7b1b5a7b34438794aed2c178decee1%7C0%7C0% 7C636452649612378558&sdata= b3VtV VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fvcalen dar.netlify.com<http://dar.netlify.com>%2F&data=02%7C01%7C% 7C203485b5b9c744aed92608d52250 0f48%7C fa7b1b5a7b34438794aed2c178decee1%7C0%7C0% 7C636452649612378558&sdata= b3Vt VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0> On Nov 2, 2017, at 12:01 PM, Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>> wrote: FYI, I worked out a theming class for my (Royale) InDesign extensions which allows for setting global CSS at runtime. The approach might be useful in your theming effort: https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fpaste.a pache.org<http://pache.org>%2FcOBC&data=02%7C01%7C% 7C203485b5b9c744aed92608d52250 0f48%7Cfa 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& sdata=bRWKxm LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Fpast e . apache.org<http://apache.org>%2FcOBC&data=02%7C01%7C% 7C203485b5b9c744aed92608d52250 0f48%7Cf a7b1b5a7b34438794aed2c178decee1%7C0%7C0% 7C636452649612378558&sdata= bRWKx mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0> (Some of the code is specific to Adobe Extensions.) Some pointers: I used inject_html because I needed some overrides in a CSS file. I might have been able to rework it so the CSS file was not needed. There is a function called createStyleSheet which is commented out. That creates a stylesheet called “royale_theme_styles”. It’s the same as including a blank css file with the same name, but it’s loaded dynamically rather than requiring the file to be included. If that function is used inject_html is not necessary. The order of dynamically loaded CSS has the same rules as CSS loaded via declaring it in HTML and the later ones override the earlier ones. We can probably take advantage of that for different levels of defaults. HTH, Harbs On Nov 1, 2017, at 8:05 PM, Carlos Rovira <carlosrov...@apache.org<mailto:carlosrov...@apache.org> <mailto:carlosrov...@apache.org>> wrote: Hi, I think I could start to try what Harbs expose, although I think what I will need in the end is to control some SVG parts with variables. Maybe with the showed SVG/CSS relation could be sufficient. I'll be showing how limitations I find. As well as Alex said having inline SVG as HTML would be very useful. 2017-11-01 18:27 GMT+01:00 Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com> <mailto: harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>>>: I’m not sure. I haven’t seen problems. The only issues that come to mind are: 1. There’s no load events on SVG images on Microsoft browsers. 2. Chrome has issues with SVG, transforms and fractional pixels. 3. There’s some blending issues that different browsers handle differently depending on isolation modes. There’s likely other issues, but these are ones that I’ve had to deal with. The major gotcha in terms of mixing HTML and SVG is that HTML can not be nested inside SVG without ForeignObject. ForeignObject does not have full browser support. On Nov 1, 2017, at 7:08 PM, Alex Harui <aha...@adobe.com.INVALID<mailto:aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID>> wrote: A couple of years ago, I thought I had learned that some browsers had issues with SVG background-images. Maybe psuedo-states were involved, but a Button might "blink" as it changed states and loaded an SVG background-image. Do we know if that was just a bug in some browser or is that still a concern? I think I would like to see a simple set of HTML/SVG/CSS/JS that shows how any declarative SVG and JS have to work together to handle resizable skins/components. Then it might be more obvious what needs to change in the tooling. We allow inline HTML now in MXML. I think we can/should allow inline SVG, but for both inline HTML and SVG, id's in the inline content do not become id's to MXML and AS. HTH, -Alex -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url= http%3A%2F%2Fabout.me<http://2Fabout.me>% 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 0f48%7Cfa7b1 b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& sdata=C7a72gwfH2 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0 -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url= http%3A%2F%2Fabout.me<http://2Fabout.me>%2 Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 0f48%7Cfa7b1b5 a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& sdata=C7a72gwfH264w Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0 -- <https://na01.safelinks.protection.outlook.com/?url= http%3A%2F%2Fwww.codeo scopic.com<http://scopic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295 d8cf%7Cfa7b1b5a7b 34438794aed2c178decee1%7C0%7C0%7C636452949347201523& sdata=Hm%2B6WIcqQTOHs0 UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0> Carlos Rovira Director General M: +34 607 22 60 05 https://na01.safelinks.protection.outlook.com/?url= http%3A%2F%2Fwww.codeos copic.com<http://copic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295 d8cf%7Cfa7b1b5a7b3 4438794aed2c178decee1%7C0%7C0%7C636452949347201523& sdata=Hm%2B6WIcqQTOHs0U ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0 Conocenos Avant2 en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url= https%3A%2F%2Favant2.e s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295 d8cf%7Cfa7b1b5a 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523& sdata=b%2FFMr1Ajit94 TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%3D&reserved=0> Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria. -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url= http%3A%2F%2Fabout.me<http://2Fabout.me>%2 Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397 82e0%7Cfa7b1b5 a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812& sdata=wYPMWW1wpTbtm pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0 -- <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0> Carlos Rovira Director General M: +34 607 22 60 05 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0 Conocenos Avant2 en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=Df4JBWaWmTrEZYwvr1NTQBLOInEPtyF92ACWbYi4%2FL4%3D&reserved=0> Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria. -- Piotr Zarzycki Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0>* -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=KwVvFzo8w1oV00kHzCxI3Wyn0UlqIfyFWnazDdPpwrk%3D&reserved=0
