Basic is going to be the base for anything. I don’t think Express is going to
be very helpful. It should probably just be built out from Basic components
and/or copied from Basic.
For an example of a styleable component, take a look at CSSCheckbox. I think
that’s a good example of a styleable component. You might be able to do better,
but I had a need for a checkbox which could be styled using CSS and I created
that class. I wanted to use a topcoat-styled checkbox, which I was able to do
using that class like this:
package com.printui.view.components
{
import org.apache.flex.html.CSSCheckBox;
public class CheckBox extends CSSCheckBox
{
public function CheckBox(){
super();
className="topcoat-checkbox";
checkClassName="topcoat-checkbox__checkmark";
}
}
}
I then used that class in my app.
There might be more elegant ways to specify classes, but this is how I did it…
Here’s what it looks like in the app:
https://www.evernote.com/l/AI_1QITiAqVCe5rgWuBlfIr3HjEQic1DhpQB/image.png
Hope this is useful,
Harbs
> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote:
>
> 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>:
>
>> 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> 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>:
>>>
>>>> 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 on behalf of Carlos
>> Rovira"
>>>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>>>>
>>>>> HI Alex,
>>>>>
>>>>>
>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <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 on behalf of Carlos
>>>>>> Rovira"
>>>>>> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <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 on behalf of Carlos
>>>>>>>> Rovira"
>>>>>>>> <carlos.rov...@gmail.com on behalf of 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
>>> :
>>>>>>>>>
>>>>>>>>>> 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>:
>>>>>>>>>>
>>>>>>>>>>> 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%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%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>
>>>>>> 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%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%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>> 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>>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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>> 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%
>>>>>>>>>> 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%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&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&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%2
>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>>>> 82e0%7Cfa7b1b5
>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>>>> sdata=wYPMWW1wpTbtm
>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> <http://www.codeoscopic.com>
>>>
>>> Carlos Rovira
>>>
>>> Director General
>>>
>>> M: +34 607 22 60 05
>>>
>>> http://www.codeoscopic.com
>>>
>>>
>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>>
>>>
>>> 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://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
