royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Idylog - Nicolas Granon" <ngra...@idylog.com>
Subject RE: Working on UI Controls styling
Date Tue, 07 Nov 2017 13:29:40 GMT
Are we talking about styling, theming or skinning ?

As application developers, we are mainly interested in "styling", based on an available theme.
Usually, it is a minor task. Most of the apps follow the chosen theme and styles affect mostly
font size/weight, borders width/color, alphas ...

We never "create" a full skin, unless we create a very specific component (complete with all
visual aspects). That is not our usual business.
Our customers expect "visual elements" (components, controls...) to have a very standardized
look.

It could happen that we need to change a theme, for example if the customer is a big company
and want the general color scheme/font to be close to the company standards.
But usually, we stick to a basic, neutral theme.

Nicolas Granon




> -----Message d'origine-----
> De : Peter Ent [mailto:pent@adobe.com.INVALID]
> Envoyé : mardi 7 novembre 2017 12:40
> À : dev@royale.apache.org
> Objet : Re: Working on UI Controls styling
> 
> A couple of questions:
> 
> How expensive is generating and applying CSS on the client?
> 
> How do developers that use CSS regularly feel about having to declare
> that many styles for all the buttons? Maybe tools like Dreamweaver make
> it simpler and we just need IDEs that could provide assistance.
> 
> Peter
> 
> 
> On Nov 7, 2017, at 6:24 AM, Harbs
> <harbs.lists@gmail.com<mailto:harbs.lists@gmail.com>> wrote:
> 
> Some food for thought:
> 
> I created a custom component for “buttons” which allow simple skinning
> using image files. It works like this:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.
> apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7C
> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tko
> afaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste
> .apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7
> Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tk
> oafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0>
> 
> Specifying different states can be done using the following css:
> .bug
> {
>    background-image: url ('assets/up/report-bug.png'); } .bug:hover{
>    background-image: url ('assets/over/report-bug.png'); } .bug:active{
>    background-image: url ('assets/down/report-bug.png'); }
> .bug:disabled{
>    background-image: url ('assets/disabled/report-bug.png');
> }
> 
> It works well, but the problem with this approach is that it requires
> multiple css entries for every button.
> 
> Using it is done like this:
>    <comp:PanelButton id="bugButton"
>               enabled="{bugReportEnabled}" width="72" height="82"
>               x="19" y="283"
>               click="reportBug()" className="bug"/>
> 
> I wanted to allow the following:
> 
>    <comp:PanelButton id="bugButton"
>               enabled="{bugReportEnabled}" width="72" height="82"
>               x="19" y="283"
>               click="reportBug()" className="bug"
>               image="assets/up/report-bug.png"
>               hoverImage="assets/over/report-bug.png"
>               activeImage="assets/down/report-bug.png"
>               disabledImage="assets/disabled/report-bug.png"/>
> 
> However, this is harder than you’d expect in HTML. Apparently there’s
> no way to set pseudo-styles using inline css.[1][2].
> 
> There are a couple of interesting work-arounds. One is using mouse
> events.[3] Another is by creating CSS on the fly.[4] The answer assumes
> that the css is created on the server, but using the ideas I proposed
> in the ThemeManager class, that can be done on the client dynamically.
> 
> The challenge with the last approach would be in guaranteeing the css
> is unique to the images (or individual component). One option on that
> front would be to generate UIDs when the component is instantiated. A
> consideration is garbage-collecting CSS selectors when components might
> be removed.
> 
> I hope these ideas are helpful.
> 
> Harbs
> 
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nq
> ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nq
> ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0>
> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-
> pseudo-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaX
> W6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-
> pseudo-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaX
> W6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0>
> [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f
> 27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364565
> 06748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&
> reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27
> c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506
> 748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&re
> served=0>
> [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4
> f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456
> 506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&r
> eserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f2
> 7c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645650
> 6748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&res
> erved=0>
> 
> On Nov 6, 2017, at 8:22 PM, Carlos Rovira
> <carlosrovira@apache.org<mailto:carlosrovira@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
> <piotrzarzycki21@gmail.com<mailto:piotrzarzycki21@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.lists@gmail.com<mailto:harbs.lists@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.rovira@codeoscopic.com<mailto:carlos.rovira@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
> <aharui@adobe.com.invalid<mailto:aharui@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.rovira@gmail.com<mailto:carlos.rovira@gmail.com> on behalf of
> Carlos Rovira"
> <carlos.rovira@gmail.com<mailto:carlos.rovira@gmail.com> on behalf of
> carlosrovira@apache.org<mailto:carlosrovira@apache.org>> wrote:
> 
> HI Alex,
> 
> 
> 2017-11-03 17:52 GMT+01:00 Alex Harui
> <aharui@adobe.com.invalid<mailto:aharui@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.rovira@gmail.com<mailto:carlos.rovira@gmail.com> on behalf of
> Carlos Rovira"
> <carlos.rovira@gmail.com<mailto:carlos.rovira@gmail.com> on behalf of
> carlos.rovira@codeoscopic.com<mailto:carlos.rovira@codeoscopic.com>
> 
> wrote:
> 
> Hi Alex,
> 
> 2017-11-03 7:39 GMT+01:00 Alex Harui
> <aharui@adobe.com.invalid<mailto:aharui@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.rovira@gmail.com<mailto:carlos.rovira@gmail.com> on behalf of
> Carlos Rovira"
> <carlos.rovira@gmail.com<mailto:carlos.rovira@gmail.com> on behalf of
> carlosrovira@apache.org<mailto:carlosrovira@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 <
> carlosrovira@apache.org<mailto:carlosrovira@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.lists@gmail.com<mailto:harbs.lists@gmail.com>>:
> 
> BTW, the kind of thing we should be striving for in theme-able
> components is something like this:
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalend
> ar.netlify.com<http://ar.netlify.com>%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cf
> 
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> b3VtV
> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalen
> dar.netlify.com<http://dar.netlify.com>%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7C
> 
> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> b3Vt
> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> 
> On Nov 2, 2017, at 12:01 PM, Harbs
> <harbs.lists@gmail.com<mailto:harbs.lists@gmail.com>>
> wrote:
> 
> FYI, I worked out a theming class for my (Royale) InDesign extensions
> which allows for setting global CSS at runtime. The approach might be
> useful in your theming effort:
> 
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.a
> pache.org<http://pache.org>%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cfa
> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=bRWKxm
> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> 
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpast
> e
> .
> apache.org<http://apache.org>%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cf
> 
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> bRWKx
> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> 
> (Some of the code is specific to Adobe Extensions.)
> 
> Some pointers:
> I used inject_html because I needed some overrides in a CSS file.
> I
> might have been able to rework it so the CSS file was not needed.
> 
> There is a function called createStyleSheet which is commented out.
> That creates a stylesheet called “royale_theme_styles”. It’s the same
> as including a blank css file with the same name, but it’s loaded
> dynamically rather than requiring the file to be included. If that
> function is used inject_html is not necessary.
> 
> The order of dynamically loaded CSS has the same rules as CSS loaded
> via declaring it in HTML and the later ones override the earlier ones.
> We
> can probably take advantage of that for different levels of defaults.
> 
> HTH,
> Harbs
> 
> On Nov 1, 2017, at 8:05 PM, Carlos Rovira
> <carlosrovira@apache.org<mailto:carlosrovira@apache.org>
> <mailto:carlosrovira@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.lists@gmail.com<mailto:harbs.lists@gmail.com>
> <mailto:
> harbs.lists@gmail.com<mailto:harbs.lists@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
> <aharui@adobe.com.INVALID<mailto:aharui@adobe.com.INVALID>
> <mailto:aharui@adobe.com.INVALID>> wrote:
> 
> A couple of years ago, I thought I had learned that some browsers had
> issues with SVG background-images.  Maybe psuedo-states were involved,
> but a Button might "blink" as it changed states and loaded an SVG
> background-image.  Do we know if that was just a bug in some browser or
> is that still a concern?
> 
> I think I would like to see a simple set of HTML/SVG/CSS/JS that shows
> how any declarative SVG and JS have to work together to handle
> resizable skins/components.  Then it might be more obvious what needs
> to change in the tooling.  We allow inline HTML now in MXML.  I think
> we can/should allow inline SVG, but for both inline HTML and SVG, id's
> in the inline content do not become id's to MXML and AS.
> 
> HTH,
> -Alex
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Carlos Rovira
> 
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%
> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1
> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH2
> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> 
> 
> 
> 
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%2
> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5
> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH264w
> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> 
> 
> 
> 
> --
> 
> <https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.codeo
> scopic.com<http://scopic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d
> 52295
> d8cf%7Cfa7b1b5a7b
> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0
> UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0>
> 
> Carlos Rovira
> 
> Director General
> 
> M: +34 607 22 60 05
> 
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.codeos
> copic.com<http://copic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52
> 295
> d8cf%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0U
> ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0
> 
> 
> Conocenos Avant2 en 1 minuto!
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Favant2.e
> s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a
> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=b%2FFMr1Ajit94
> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%3D&reserved=0>
> 
> 
> Este mensaje se dirige exclusivamente a su destinatario y puede
> contener información privilegiada o confidencial. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
> 
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> comunicamos que sus datos forman parte de un fichero cuyo responsable
> es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la
> prestación del servicio o información solicitados, teniendo usted
> derecho de acceso, rectificación, cancelación y oposición de sus datos
> dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036,
> Madrid con la documentación necesaria.
> 
> 
> 
> 
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%2
> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> 82e0%7Cfa7b1b5
> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> sdata=wYPMWW1wpTbtm
> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
> 
> 
> 
> 
> --
> 
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
> deoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b
> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ9
> 5n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0>
> 
> Carlos Rovira
> 
> Director General
> 
> M: +34 607 22 60 05
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cod
> eoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1
> b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95
> n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0
> 
> 
> Conocenos Avant2 en 1 minuto!
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant
> 2.es%2F%23video&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa
> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=Df4JB
> WaWmTrEZYwvr1NTQBLOInEPtyF92ACWbYi4%2FL4%3D&reserved=0>
> 
> 
> Este mensaje se dirige exclusivamente a su destinatario y puede
> contener información privilegiada o confidencial. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
> 
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> comunicamos que sus datos forman parte de un fichero cuyo responsable
> es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la
> prestación del servicio o información solicitados, teniendo usted
> derecho de acceso, rectificación, cancelación y oposición de sus datos
> dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036,
> Madrid con la documentación necesaria.
> 
> 
> 
> 
> --
> 
> Piotr Zarzycki
> 
> Patreon:
> *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p
> atreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525
> d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&
> sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p
> atreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525
> d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&
> sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0>*
> 
> 
> 
> 
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m
> e%2Fcarlosrovira&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cf
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=KwVv
> Fzo8w1oV00kHzCxI3Wyn0UlqIfyFWnazDdPpwrk%3D&reserved=0




Mime
View raw message