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.
