Are we talking about styling, theming or skinning ? As application developers, we are mainly interested in "styling", based on an available theme. Usually, it is a minor task. Most of the apps follow the chosen theme and styles affect mostly font size/weight, borders width/color, alphas ...
We never "create" a full skin, unless we create a very specific component (complete with all visual aspects). That is not our usual business. Our customers expect "visual elements" (components, controls...) to have a very standardized look. It could happen that we need to change a theme, for example if the customer is a big company and want the general color scheme/font to be close to the company standards. But usually, we stick to a basic, neutral theme. Nicolas Granon > -----Message d'origine----- > De : Peter Ent [mailto:p...@adobe.com.INVALID] > Envoyé : mardi 7 novembre 2017 12:40 > À : dev@royale.apache.org > Objet : Re: Working on UI Controls styling > > 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%7C > fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tko > afaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste > .apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7 > Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tk > oafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%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%2Fsta > ckoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline- > styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3 > 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nq > ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack > overflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline- > styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3 > 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nq > ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0> > [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta > ckoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline- > pseudo- > styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3 > 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaX > W6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack > overflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline- > pseudo- > styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3 > 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaX > W6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0> > [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta > ckoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f > 27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364565 > 06748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D& > reserved=0 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack > overflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27 > c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506 > 748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&re > served=0> > [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta > ckoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4 > f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456 > 506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&r > eserved=0 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack > overflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f2 > 7c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645650 > 6748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&res > erved=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%7C6422929d95d1406eaa1c08d > 52295 > 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%7C6422929d95d1406eaa1c08d52 > 295 > 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.co > deoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b > 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ9 > 5n%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.cod > eoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1 > b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95 > n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0 > > > Conocenos Avant2 en 1 minuto! > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant > 2.es%2F%23video&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa > 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=Df4JB > WaWmTrEZYwvr1NTQBLOInEPtyF92ACWbYi4%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.p > atreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525 > d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243& > sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p > atreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525 > d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243& > sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0>* > > > > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m > e%2Fcarlosrovira&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cf > a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=KwVv > Fzo8w1oV00kHzCxI3Wyn0UlqIfyFWnazDdPpwrk%3D&reserved=0
