+1.
> On Nov 6, 2017, at 8:22 PM, Carlos Rovira <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>:
>
>> 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>*
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
