AFAIK, generating should not be any slower than any other DOM node. Here’s some data on applying CSS (although I’m not sure how useful the info actually is): https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/ <https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/>
How developers in general feel about it? No idea. But I find CSS files difficult to deal with. > On Nov 7, 2017, at 1:39 PM, Peter Ent <[email protected]> wrote: > > 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 > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>>: > > 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 > <[email protected]<mailto:[email protected]>>: > > 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 < > [email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>>: > > 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, "[email protected]<mailto:[email protected]> > on behalf of Carlos > Rovira" > <[email protected]<mailto:[email protected]> on behalf of > [email protected]<mailto:[email protected]>> wrote: > > HI Alex, > > > 2017-11-03 17:52 GMT+01:00 Alex Harui > <[email protected]<mailto:[email protected]>>: > > 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, "[email protected]<mailto:[email protected]> > on behalf of Carlos > Rovira" > <[email protected]<mailto:[email protected]> on behalf of > [email protected]<mailto:[email protected]> > > wrote: > > Hi Alex, > > 2017-11-03 7:39 GMT+01:00 Alex Harui > <[email protected]<mailto:[email protected]>>: > > 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, "[email protected]<mailto:[email protected]> > on behalf of Carlos > Rovira" > <[email protected]<mailto:[email protected]> on behalf of > [email protected]<mailto:[email protected]>> > 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 < > [email protected]<mailto:[email protected]> > : > > 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 > <[email protected]<mailto:[email protected]>>: > > 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 > <[email protected]<mailto:[email protected]>> > 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 > <[email protected]<mailto:[email protected]> > <mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]> > <mailto: > [email protected]<mailto:[email protected]>>>: > > 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 > <[email protected]<mailto:[email protected]> > <mailto:[email protected]>> 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 >
