You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by jude <fl...@gmail.com> on 2015/03/08 05:06:31 UTC
[DISCUSSION] MXML pseudo states suggestion
In CSS you can address certain states of a component using pseudo states
(states) like so:
s|Button#iconOnlyButton:up {
icon: "assets/upImage.png";
}
s|Button#iconOnlyButton:over {
icon: "assets/overImage.png";
}
s|Button#iconOnlyButton:down {
icon: "assets/downImage.png";
}
But you can't do the same thing in MXML.
You *can* address document level states in MXML like so:
<s:Button icon="default.png" icon.about="about.png"/>
<s:states>
<s:State name="home" />
<s:State name="gallery" />
<s:State name="feedback" />
</s:states>
But that doesn't let you assign values to states of the component. This
will throw an error:
<s:Button icon="default.png" icon.up="about.png"/>
While this CSS will not:
s|Button#iconOnlyButton:up {
icon: "about.png";
}
Is it possible to add support for inline pseudo states like we do with CSS?
Does anyone else want this? How would we do it?
Jude
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
OK. Does anyone have any ideas, contributions or feature requests before I
look into this further?
Do any of the compiler guys have any thoughts? I was going to ask Gordon
Smith for his thoughts here but legend has it the only way to contact him
is to type his name 3 times into command line at midnight during a full
moon and you can ask him one question. If you ask two questions I hear you
get the blue screen of death and the only way to restore your computer is
to burn a floppy disk of HomeSite 5.0.
On Mon, Mar 16, 2015 at 12:02 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/15/15, 10:42 PM, "jude" <fl...@gmail.com> wrote:
>
> >OK so we would add an overrides array on UIComponent and when the state is
> >changing check for any overrides and apply them?
>
> No idea exactly what to do here. I think there are several choices:
> -Adding another property to UIComponent
> -Adding a data structure(s) to the MXML document
> -Adding a data structure(s) to the instance’s MXML document.
>
> The main downside of the first is that all UIComponent instances carry the
> extra property regardless of whether they are actually involved in this
> pseudo-states scheme. All three still have the challenge of when it is
> the component’s skin and not the actual component that changes state.
>
> >Then in the compiler when
> >we encounter a pseudo state attribute we add these to the instance's
> >overrides array?
>
> For sure, the compiler needs to build up an array of overrides.
>
> -Alex
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
On 3/15/15, 10:42 PM, "jude" <fl...@gmail.com> wrote:
>OK so we would add an overrides array on UIComponent and when the state is
>changing check for any overrides and apply them?
No idea exactly what to do here. I think there are several choices:
-Adding another property to UIComponent
-Adding a data structure(s) to the MXML document
-Adding a data structure(s) to the instance’s MXML document.
The main downside of the first is that all UIComponent instances carry the
extra property regardless of whether they are actually involved in this
pseudo-states scheme. All three still have the challenge of when it is
the component’s skin and not the actual component that changes state.
>Then in the compiler when
>we encounter a pseudo state attribute we add these to the instance's
>overrides array?
For sure, the compiler needs to build up an array of overrides.
-Alex
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
OK so we would add an overrides array on UIComponent and when the state is
changing check for any overrides and apply them? Then in the compiler when
we encounter a pseudo state attribute we add these to the instance's
overrides array?
On Sat, Mar 14, 2015 at 10:21 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/14/15, 10:36 AM, "jude" <fl...@gmail.com> wrote:
>
> >I forgot about someone overriding setStyle. Right, so what about a method
> >like setStyleInState()?
> >
> >I'm thinking of supporting both styles and properties.
> >
> >If it's a style we create a mx.states.SetStyle and for properties we
> >create
> >a mx.states.SetAction and add to the state's overrides array.
>
> I could be wrong, but my current thinking is that if you are going to
> support both styles and properties, you don’t need any changes to
> StyleManager. State overrides are simply deferred calls to setStyle and
> various property setters. Even more important, as you return from that
> state back to some other state, the original style or property value gets
> applied. I don’t think you want to add and remove CSS Selectors. It will
> be too expensive and could affect other parts of the DOM.
>
> So, I think this feature should be independent of the CSS/StyleManager
> subsystem. I think what you really want is a way to store other overrides
> to be applied on state changes in various instances.
>
> -Alex
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
On 3/14/15, 10:36 AM, "jude" <fl...@gmail.com> wrote:
>I forgot about someone overriding setStyle. Right, so what about a method
>like setStyleInState()?
>
>I'm thinking of supporting both styles and properties.
>
>If it's a style we create a mx.states.SetStyle and for properties we
>create
>a mx.states.SetAction and add to the state's overrides array.
I could be wrong, but my current thinking is that if you are going to
support both styles and properties, you don’t need any changes to
StyleManager. State overrides are simply deferred calls to setStyle and
various property setters. Even more important, as you return from that
state back to some other state, the original style or property value gets
applied. I don’t think you want to add and remove CSS Selectors. It will
be too expensive and could affect other parts of the DOM.
So, I think this feature should be independent of the CSS/StyleManager
subsystem. I think what you really want is a way to store other overrides
to be applied on state changes in various instances.
-Alex
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
I forgot about someone overriding setStyle. Right, so what about a method
like setStyleInState()?
I'm thinking of supporting both styles and properties.
If it's a style we create a mx.states.SetStyle and for properties we create
a mx.states.SetAction and add to the state's overrides array.
On Thursday, March 12, 2015, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/12/15, 1:39 PM, "jude" <flexcapacitor@gmail.com <javascript:;>>
> wrote:
>
> >OK now I see the states generated code. I've seen this before. Right, it's
> >creating a new SetStyle instance. It's creating that at the document
> >level.
> >I hear your points and they are valid. I think we could work around it.
>
> I agree. I just wanted to make sure you understood the current mechanism.
>
> >
> >But I think it will be OK to modify setStyle().
>
> Well, anyone who has overridden setStyle in a third party component will
> break as soon as you change the signature. That’s just the way AS and the
> VM work. It is true that any existing calls to setStyle can continue to
> work, but IMO, the upheaval in third-party components is too high to be
> making a change to setStyle’s parameter list. It is probably better just
> to add a new method.
>
> > // do new stuff here - Alex writes this part
>
> Uhh, no. Judah’s going to write this part ;-)
>
> >
> >The part where it says do new stuff here we could dynamically create the
> >mx.states.setStyle action and add it to the overrides. Or we dynamically
> >create the new CSSCondition("pseudo", "up"); and create a new selector.
> >There would be the possibly for the same property or style to be assigned
> >twice as you mentioned. We could create a warning, throw an error at
> >runtime or just let the last one in win.
> >
>
> Is this just limited to styles or are you going to allow setting regular
> properties? If the latter, then I think you are trying to add to the set
> of overrides.
>
> -Alex
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
On 3/12/15, 1:39 PM, "jude" <fl...@gmail.com> wrote:
>OK now I see the states generated code. I've seen this before. Right, it's
>creating a new SetStyle instance. It's creating that at the document
>level.
>I hear your points and they are valid. I think we could work around it.
I agree. I just wanted to make sure you understood the current mechanism.
>
>But I think it will be OK to modify setStyle().
Well, anyone who has overridden setStyle in a third party component will
break as soon as you change the signature. That’s just the way AS and the
VM work. It is true that any existing calls to setStyle can continue to
work, but IMO, the upheaval in third-party components is too high to be
making a change to setStyle’s parameter list. It is probably better just
to add a new method.
> // do new stuff here - Alex writes this part
Uhh, no. Judah’s going to write this part ;-)
>
>The part where it says do new stuff here we could dynamically create the
>mx.states.setStyle action and add it to the overrides. Or we dynamically
>create the new CSSCondition("pseudo", "up"); and create a new selector.
>There would be the possibly for the same property or style to be assigned
>twice as you mentioned. We could create a warning, throw an error at
>runtime or just let the last one in win.
>
Is this just limited to styles or are you going to allow setting regular
properties? If the latter, then I think you are trying to add to the set
of overrides.
-Alex
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
OK now I see the states generated code. I've seen this before. Right, it's
creating a new SetStyle instance. It's creating that at the document level.
I hear your points and they are valid. I think we could work around it.
I'm not saying there won't be conflicts but there are conflicts now with
CSS when you declare and set a style twice. In that case it's handled by
specificity. When creating transitions there is plenty of room for errors
as well.
But I think it will be OK to modify setStyle(). With the setStyle() API it
only accepts two arguments. We could add two more optional arguments and
that would not cause any backwards compatibility issues since they will
continue to work the same.
OLD:
public function setStyle(styleProp:String, newValue:*):void
{
// If there is no module factory then defer the set
// style until a module factory is set.
if (moduleFactory)
{
StyleProtoChain.setStyle(this, styleProp, newValue);
}
else
{
if (!deferredSetStyles)
deferredSetStyles = {};
deferredSetStyles[styleProp] = newValue;
}
}
NEW:
public function setStyle(styleProp:String, newValue:*, state:* = null,
documentState:Boolean = true):void
{
// If state is set then do new stuff
if (state)
{
// do new stuff here - Alex writes this part
}
else { // do previous stuff
// If there is no module factory then defer the set
// style until a module factory is set.
if (moduleFactory)
{
StyleProtoChain.setStyle(this, styleProp, newValue);
}
else
{
if (!deferredSetStyles)
deferredSetStyles = {};
deferredSetStyles[styleProp] = newValue;
}
}
}
The part where it says do new stuff here we could dynamically create the
mx.states.setStyle action and add it to the overrides. Or we dynamically
create the new CSSCondition("pseudo", "up"); and create a new selector.
There would be the possibly for the same property or style to be assigned
twice as you mentioned. We could create a warning, throw an error at
runtime or just let the last one in win.
On Tue, Mar 10, 2015 at 11:19 AM, Alex Harui <ah...@adobe.com> wrote:
> Hi Judah,
>
> I think your example from a few posts ago didn’t actually have a
> state-dependent attribute. Maybe try something like this:
>
> <s:states>
> <s:State name=“jude” />
> </s:states>
> <controls:ImageButton id="myButton" label="a long label test"
> icon.jude="assets/lagoon.jpg" />
>
>
> I think there might be too many backward-compatibility risks with changing
> the API signature of setStyle. The compiler could certainly generate a
> call to another API though, but I think if you look at the generated code
> for a state-dependent attribute you’ll see that the compiler doesn’t
> generate call to setStyle but actually uses a States class like
> mx.states.SetStyle.
>
> -Alex
>
> On 3/10/15, 10:48 AM, "jude" <fl...@gmail.com> wrote:
>
> >The TL;DR was what if we treat inline pseudo states MXML like it is an
> >inline style or like we treat CSS pseudo style declarations? When we
> >encounter an attribute formatted like so, icon#up="myUpIcon.png" we,
> >meaning the compiler, write out:
> >
> >temp.setStyle("icon", "myUpIcon.png", "up", true); // create a css pseudo
> >condition for the "up" state
> >
> >Normally if we encounter a style inline we write out:
> >
> >temp.setStyle("icon", "myUpIcon.png"); // generated by the compiler for
> >the
> >inline style. see the previous email
> >
> >We would have to add support by adding additional parameters to setStyles
> >for different states in the setStyle method at the very least.
> >
> >Basically, <s:Button id="myButton" icon#up="myUpIcon.png" /> would be the
> >same as writing this:
> >
> >s|Button#myButton:up {
> > icon:"myUpIcon.png"
> >}
> >
> >which is the same as or similar to:
> >
> >condition = new CSSCondition("pseudo", "up");
> >style =
> >styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:u
> >p");
> >style.factory = function():void
> >{
> > this.icon = "myUpIcon.png";
> >};
> >
> >But we create that code above specifically for that button instance at
> >runtime when setStyle("icon", "myUpIcon.png", "up", true) is called. We
> >might even be able to get rid of some generated style declarations if we
> >can use setStyle() to create the CSSConditions.
> >
> >@Kessler - I didn't notice that method before. I'll check it out.
> >
> >@Alex - I'll look at the states generated code again too. There might be
> >collisions with the states generated code.
> >
> >you wrote,
> >"I think you missed some of the generated code for the state-dependent
> >properties and styles. Take a look at how the assignment for a
> >state-dependent style attribute look"
> >
> >I'm looking at the generated files and I don't see anything. What MXML
> >would generate this or what files should I be looking for? In my last
> >message I copied in the generated code for an MXML declared Spark Button
> >and the generated code for a CSS declaration for a pseudo state. Both of
> >the codes appeared in the generated application file,
> >PseudoStatesExample-generated.as. Is this the same as what you were
> >referring to? Sorry the original was so long.
> >
> >
> >On Tue, Mar 10, 2015 at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Maybe, but the way the code currently works is that the states are
> >> declared in an MXML document and all state-dependent data is generated
> >>for
> >> that same document. While that state-dependent code does set styles and
> >> properties on other instances declared in that document, some of those
> >> instances are themselves MXML documents for which their state-dependent
> >> code has already been generated, probably when it was compiled into a
> >>SWC.
> >> There’s no way to modify that generated code, so we need a different
> >>way
> >> to determine when a state changes in a child object (yes, there events
> >>for
> >> that) and then make the appropriate changes and figure out how to deal
> >> with potential conflicts and what to do if the child object (or
> >>actually,
> >> its skin) doesn’t support the state you think it does.
> >>
> >> -Alex
> >>
> >> On 3/10/15, 4:53 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
> >> wrote:
> >>
> >> >Is this something that could be accomplished by overriding the
> >> >stateChanged[1] protected method since it's used for setting styles
> >>when
> >> >the state changes?
> >> >
> >> >[1]
> >> >
> >>
> >>
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/cor
> >>e
> >> >/UIComponent.html#stateChanged()
> >> >
> >> >
> >> >-Mark
> >>
> >>
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
Hi Judah,
I think your example from a few posts ago didn’t actually have a
state-dependent attribute. Maybe try something like this:
<s:states>
<s:State name=“jude” />
</s:states>
<controls:ImageButton id="myButton" label="a long label test"
icon.jude="assets/lagoon.jpg" />
I think there might be too many backward-compatibility risks with changing
the API signature of setStyle. The compiler could certainly generate a
call to another API though, but I think if you look at the generated code
for a state-dependent attribute you’ll see that the compiler doesn’t
generate call to setStyle but actually uses a States class like
mx.states.SetStyle.
-Alex
On 3/10/15, 10:48 AM, "jude" <fl...@gmail.com> wrote:
>The TL;DR was what if we treat inline pseudo states MXML like it is an
>inline style or like we treat CSS pseudo style declarations? When we
>encounter an attribute formatted like so, icon#up="myUpIcon.png" we,
>meaning the compiler, write out:
>
>temp.setStyle("icon", "myUpIcon.png", "up", true); // create a css pseudo
>condition for the "up" state
>
>Normally if we encounter a style inline we write out:
>
>temp.setStyle("icon", "myUpIcon.png"); // generated by the compiler for
>the
>inline style. see the previous email
>
>We would have to add support by adding additional parameters to setStyles
>for different states in the setStyle method at the very least.
>
>Basically, <s:Button id="myButton" icon#up="myUpIcon.png" /> would be the
>same as writing this:
>
>s|Button#myButton:up {
> icon:"myUpIcon.png"
>}
>
>which is the same as or similar to:
>
>condition = new CSSCondition("pseudo", "up");
>style =
>styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:u
>p");
>style.factory = function():void
>{
> this.icon = "myUpIcon.png";
>};
>
>But we create that code above specifically for that button instance at
>runtime when setStyle("icon", "myUpIcon.png", "up", true) is called. We
>might even be able to get rid of some generated style declarations if we
>can use setStyle() to create the CSSConditions.
>
>@Kessler - I didn't notice that method before. I'll check it out.
>
>@Alex - I'll look at the states generated code again too. There might be
>collisions with the states generated code.
>
>you wrote,
>"I think you missed some of the generated code for the state-dependent
>properties and styles. Take a look at how the assignment for a
>state-dependent style attribute look"
>
>I'm looking at the generated files and I don't see anything. What MXML
>would generate this or what files should I be looking for? In my last
>message I copied in the generated code for an MXML declared Spark Button
>and the generated code for a CSS declaration for a pseudo state. Both of
>the codes appeared in the generated application file,
>PseudoStatesExample-generated.as. Is this the same as what you were
>referring to? Sorry the original was so long.
>
>
>On Tue, Mar 10, 2015 at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> Maybe, but the way the code currently works is that the states are
>> declared in an MXML document and all state-dependent data is generated
>>for
>> that same document. While that state-dependent code does set styles and
>> properties on other instances declared in that document, some of those
>> instances are themselves MXML documents for which their state-dependent
>> code has already been generated, probably when it was compiled into a
>>SWC.
>> There’s no way to modify that generated code, so we need a different
>>way
>> to determine when a state changes in a child object (yes, there events
>>for
>> that) and then make the appropriate changes and figure out how to deal
>> with potential conflicts and what to do if the child object (or
>>actually,
>> its skin) doesn’t support the state you think it does.
>>
>> -Alex
>>
>> On 3/10/15, 4:53 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
>> wrote:
>>
>> >Is this something that could be accomplished by overriding the
>> >stateChanged[1] protected method since it's used for setting styles
>>when
>> >the state changes?
>> >
>> >[1]
>> >
>>
>>http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/cor
>>e
>> >/UIComponent.html#stateChanged()
>> >
>> >
>> >-Mark
>>
>>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
The TL;DR was what if we treat inline pseudo states MXML like it is an
inline style or like we treat CSS pseudo style declarations? When we
encounter an attribute formatted like so, icon#up="myUpIcon.png" we,
meaning the compiler, write out:
temp.setStyle("icon", "myUpIcon.png", "up", true); // create a css pseudo
condition for the "up" state
Normally if we encounter a style inline we write out:
temp.setStyle("icon", "myUpIcon.png"); // generated by the compiler for the
inline style. see the previous email
We would have to add support by adding additional parameters to setStyles
for different states in the setStyle method at the very least.
Basically, <s:Button id="myButton" icon#up="myUpIcon.png" /> would be the
same as writing this:
s|Button#myButton:up {
icon:"myUpIcon.png"
}
which is the same as or similar to:
condition = new CSSCondition("pseudo", "up");
style =
styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:up");
style.factory = function():void
{
this.icon = "myUpIcon.png";
};
But we create that code above specifically for that button instance at
runtime when setStyle("icon", "myUpIcon.png", "up", true) is called. We
might even be able to get rid of some generated style declarations if we
can use setStyle() to create the CSSConditions.
@Kessler - I didn't notice that method before. I'll check it out.
@Alex - I'll look at the states generated code again too. There might be
collisions with the states generated code.
you wrote,
"I think you missed some of the generated code for the state-dependent
properties and styles. Take a look at how the assignment for a
state-dependent style attribute look"
I'm looking at the generated files and I don't see anything. What MXML
would generate this or what files should I be looking for? In my last
message I copied in the generated code for an MXML declared Spark Button
and the generated code for a CSS declaration for a pseudo state. Both of
the codes appeared in the generated application file,
PseudoStatesExample-generated.as. Is this the same as what you were
referring to? Sorry the original was so long.
On Tue, Mar 10, 2015 at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
> Maybe, but the way the code currently works is that the states are
> declared in an MXML document and all state-dependent data is generated for
> that same document. While that state-dependent code does set styles and
> properties on other instances declared in that document, some of those
> instances are themselves MXML documents for which their state-dependent
> code has already been generated, probably when it was compiled into a SWC.
> There’s no way to modify that generated code, so we need a different way
> to determine when a state changes in a child object (yes, there events for
> that) and then make the appropriate changes and figure out how to deal
> with potential conflicts and what to do if the child object (or actually,
> its skin) doesn’t support the state you think it does.
>
> -Alex
>
> On 3/10/15, 4:53 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
> wrote:
>
> >Is this something that could be accomplished by overriding the
> >stateChanged[1] protected method since it's used for setting styles when
> >the state changes?
> >
> >[1]
> >
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core
> >/UIComponent.html#stateChanged()
> >
> >
> >-Mark
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
Maybe, but the way the code currently works is that the states are
declared in an MXML document and all state-dependent data is generated for
that same document. While that state-dependent code does set styles and
properties on other instances declared in that document, some of those
instances are themselves MXML documents for which their state-dependent
code has already been generated, probably when it was compiled into a SWC.
There’s no way to modify that generated code, so we need a different way
to determine when a state changes in a child object (yes, there events for
that) and then make the appropriate changes and figure out how to deal
with potential conflicts and what to do if the child object (or actually,
its skin) doesn’t support the state you think it does.
-Alex
On 3/10/15, 4:53 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
wrote:
>Is this something that could be accomplished by overriding the
>stateChanged[1] protected method since it's used for setting styles when
>the state changes?
>
>[1]
>http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core
>/UIComponent.html#stateChanged()
>
>
>-Mark
RE: [DISCUSSION] MXML pseudo states suggestion
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Is this something that could be accomplished by overriding the stateChanged[1] protected method since it's used for setting styles when the state changes?
[1] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/UIComponent.html#stateChanged()
-Mark
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
Hi Judah,
I didn’t read your entire post. I think you missed some of the generated
code for the state-dependent properties and styles. Take a look at how
the assignment for a state-dependent style attribute looks and consider
whether it would change your mind about what you want to do.
-Alex
On 3/9/15, 9:50 PM, "jude" <fl...@gmail.com> wrote:
>What is the subtree? Do you mean that a CSS declaration,
>"s|Button#myButton" would match a button named myButton in two different
>documents or views? Yeah, that's a possibility.
>
>I looked at the generated code and here is the MXML and generated code for
>an ImageButton class:
>
><controls:ImageButton id="myButton" label="a long label test"
>icon="assets/lagoon.jpg" />
>
>generates:
>
>private function _PseudoStatesTest_ImageButton1_i() :
>com.flexcapacitor.controls.ImageButton
>{
> var temp : com.flexcapacitor.controls.ImageButton = new
>com.flexcapacitor.controls.ImageButton();
> temp.label = "a long label test";
> temp.setStyle("icon", "assets/lagoon.jpg");
> temp.id = "myButton";
> if (!temp.document) temp.document = this;
> myButton = temp;
> mx.binding.BindingManager.executeBindings(this, "myButton", myButton);
> return temp;
>}
>
>Here is the CSS and generated code for the pseudo states declaration:
>
> controls|ImageButton:up {
> backgroundColor:red;
> backgroundAlpha:1;
> }
>
>generates:
>
>
> selector = null;
> conditions = null;
> conditions = [];
> condition = new CSSCondition("pseudo", "up");
> conditions.push(condition);
> selector = new
>CSSSelector("com.flexcapacitor.controls.ImageButton", conditions,
>selector);
> // com.flexcapacitor.controls.ImageButton:up
> style =
>styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:u
>p");
> if (!style)
> {
> style = new CSSStyleDeclaration(selector, styleManager);
> }
>
> if (style.factory == null)
> {
> style.factory = function():void
> {
> this.backgroundColor = 0xFF0000;
> this.backgroundAlpha = 1;
> };
> }
>
>
>The component is created in the application's constructor. The styles are
>created in the application styles init. I'm not sure when the
>application's
>style init method is called but it seems it would have to be called some
>time after the application's constructor.
>
>We may have an opportunity to set the style when the component is created
>if we update the compiler and the setStyle method. So when we are creating
>the component we are setting the "icon" style with this line:
>
>private function _PseudoStatesTest_ImageButton1_i() :
>com.flexcapacitor.controls.ImageButton
>{
> //...
> temp.setStyle("icon", "assets/lagoon.jpg");
> //...
>}
>
>If we modified setStyle to accept pseudo states as a third parameter we
>could do something like this:
>
>private function _PseudoStatesTest_ImageButton1_i() :
>com.flexcapacitor.controls.ImageButton
>{
> //...
> temp.setStyle("icon", "assets/lagoon.jpg");
> temp.setStyle("icon", "assets/lagoon_up_image.jpg", "up");
> //...
>}
>
>We could also modify getStyle with a third parameter to get the value in a
>different state:
>
> var s:String = temp.getStyle("icon", "up"); //
>assets/lagoon_up_image.jpg
>
>Currently, there is no way to get the value of a style from a different
>state with these methods. But if we are going to add pseudo states we
>might
>as well support getting and setting document level state values in AS3 and
>make pseudo state values a fourth option:
>
> temp.getStyle("icon", "about", false); // get the value of icon in the
>"about" document state
> temp.getStyle("icon", "up", true); // get the value of icon in the
>current target "up" pseudo state
>
>
> temp.setStyle("icon", "assets/lagoon.jpg", "about", false); // set the
>icon value in the about state
> temp.setStyle("icon", "assets/lagoon_up_image.jpg", "up", true); //
>set
>the icon value in the current target pseudo "up" state
>
>
>So the compiler would write the correct setStyle syntax when it
>encountered
>pseudo states and the setStyle method would handle creating the pseudo
>states and conditions in the same way the CSS declarations are creating
>them (see the generated controls|ImageButton:up code above) and the
>setStyle method could create them at runtime without the compilers
>generated code from the CSS.
>
>
>
>On Mon, Mar 9, 2015 at 2:11 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> First of all, technically, you are sort of trying to do this:
>>
>> <s:Button>
>> <s:skin>
>> <s:ButtonSkin icon.up=“upImage.png” />
>> </s:skin>
>> </s:Button>
>>
>> The Button itself may not have an icon property, and the Button itself
>> doesn’t have a set of states like “up”.
>>
>> So, setting the currentState on Button may not have any effect, and
>>might
>> not have an effect if the Skin itself doesn’t support such a state, or
>> throw an exception if that state doesn’t exist. Thus, you are trying to
>> skip a level of abstraction which can be tricky and I think makes the
>> problem harder.
>>
>> I’m not saying it isn’t worth doing, just thinking about how hard it
>>will
>> be.
>>
>> CSS is interesting in that it doesn’t set a property per-se. It can be
>> thought of as a filter on the DOM. It searches using Selector subjects
>> and if it finds a match, applies the rules. The danger is that if you
>> accidentally have the same subtree somewhere else in the DOM it also
>> matches and changes. Pseudo-states are part of the filter/selection.
>> There is no way to do inline pseudo styles in HTML markup either.
>>
>> -Alex
>>
>> On 3/8/15, 11:45 AM, "jude" <fl...@gmail.com> wrote:
>>
>> >Hmm. I don't have any problem with using the "icon.up" in the MXML
>>skin.
>> >I'm thinking of the occasion in the example.
>> >
>> >We could still declare the states property changes generated code as
>>part
>> >of the document except when we set a skin state we set the component
>> >instance.currentState instead of currentState.
>> >
>> >Doesn't UIComponent have a states property? We could assign the state's
>> >values when we assign the skin. The skin has a list of its states
>>correct?
>> >Sorry on mobile.
>> >
>> >We could have a different syntax for it:
>> >
>> >icon:up="upImage.png"
>> >
>> >icon::up="upImage.png"
>> >
>> >icon@up="upImage.png"
>> >
>> >icon#up="upImage.png"
>> >
>> >Not sure if these examples will show up. the problem with the first
>>two is
>> >that a colon + any character turns into emoticons. So posting examples
>> >online and chat might get translated.
>> >
>> >I'll have to look at the code but when we have CSS that uses pseudo
>>states
>> >we use that same code when we encounter inline MXML pseudo state
>> >syntax,"icon#up".
>> >
>> >On Saturday, March 7, 2015, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >> Interesting. I get why you would want that.
>> >>
>> >> States are declared as part of the document. So “icon.about” tells
>>the
>> >> compiler to set the icon when the MXML file changes currentState to
>> >> “about”. The Button skin, if it were defined in MXML, would have the
>> >>“up”
>> >> state, not necessarily the MXML file that contains the Button. The
>> >> generated code in the containing MXML doesn’t know anything about
>> >>Button’s
>> >> skin’s states since even the skin itself can be assigned at runtime
>>or
>> >>via
>> >> CSS. Feels a bit like piercing an abstraction boundary, but I get
>>that
>> >> CSS lets you do it. Does it feel too unnatural to have to use
>>icon.up
>> >>in
>> >> the Button’s skin?
>> >>
>> >> -Alex
>> >>
>> >> On 3/7/15, 9:34 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com
>> >> <javascript:;>> wrote:
>> >>
>> >> >This sounds like a fantastic idea. It would be a bonus if we could
>>get
>> >> >the
>> >> >same state names auto-complete feature to work in CSS as well.
>> >> >
>> >> >Thanks,
>> >> >Om
>> >> >On Mar 7, 2015 8:08 PM, "jude" <flexcapacitor@gmail.com
>> <javascript:;>>
>> >> wrote:
>> >> >
>> >> >> In CSS you can address certain states of a component using pseudo
>> >>states
>> >> >> (states) like so:
>> >> >>
>> >> >> s|Button#iconOnlyButton:up {
>> >> >> icon: "assets/upImage.png";
>> >> >> }
>> >> >> s|Button#iconOnlyButton:over {
>> >> >> icon: "assets/overImage.png";
>> >> >> }
>> >> >> s|Button#iconOnlyButton:down {
>> >> >> icon: "assets/downImage.png";
>> >> >> }
>> >> >>
>> >> >> But you can't do the same thing in MXML.
>> >> >>
>> >> >> You *can* address document level states in MXML like so:
>> >> >>
>> >> >> <s:Button icon="default.png" icon.about="about.png"/>
>> >> >>
>> >> >> <s:states>
>> >> >> <s:State name="home" />
>> >> >> <s:State name="gallery" />
>> >> >> <s:State name="feedback" />
>> >> >> </s:states>
>> >> >>
>> >> >> But that doesn't let you assign values to states of the component.
>> >>This
>> >> >> will throw an error:
>> >> >>
>> >> >> <s:Button icon="default.png" icon.up="about.png"/>
>> >> >>
>> >> >> While this CSS will not:
>> >> >>
>> >> >> s|Button#iconOnlyButton:up {
>> >> >> icon: "about.png";
>> >> >> }
>> >> >>
>> >> >> Is it possible to add support for inline pseudo states like we do
>> >>with
>> >> >>CSS?
>> >> >> Does anyone else want this? How would we do it?
>> >> >>
>> >> >> Jude
>> >> >>
>> >>
>> >>
>>
>>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
What is the subtree? Do you mean that a CSS declaration,
"s|Button#myButton" would match a button named myButton in two different
documents or views? Yeah, that's a possibility.
I looked at the generated code and here is the MXML and generated code for
an ImageButton class:
<controls:ImageButton id="myButton" label="a long label test"
icon="assets/lagoon.jpg" />
generates:
private function _PseudoStatesTest_ImageButton1_i() :
com.flexcapacitor.controls.ImageButton
{
var temp : com.flexcapacitor.controls.ImageButton = new
com.flexcapacitor.controls.ImageButton();
temp.label = "a long label test";
temp.setStyle("icon", "assets/lagoon.jpg");
temp.id = "myButton";
if (!temp.document) temp.document = this;
myButton = temp;
mx.binding.BindingManager.executeBindings(this, "myButton", myButton);
return temp;
}
Here is the CSS and generated code for the pseudo states declaration:
controls|ImageButton:up {
backgroundColor:red;
backgroundAlpha:1;
}
generates:
selector = null;
conditions = null;
conditions = [];
condition = new CSSCondition("pseudo", "up");
conditions.push(condition);
selector = new
CSSSelector("com.flexcapacitor.controls.ImageButton", conditions, selector);
// com.flexcapacitor.controls.ImageButton:up
style =
styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:up");
if (!style)
{
style = new CSSStyleDeclaration(selector, styleManager);
}
if (style.factory == null)
{
style.factory = function():void
{
this.backgroundColor = 0xFF0000;
this.backgroundAlpha = 1;
};
}
The component is created in the application's constructor. The styles are
created in the application styles init. I'm not sure when the application's
style init method is called but it seems it would have to be called some
time after the application's constructor.
We may have an opportunity to set the style when the component is created
if we update the compiler and the setStyle method. So when we are creating
the component we are setting the "icon" style with this line:
private function _PseudoStatesTest_ImageButton1_i() :
com.flexcapacitor.controls.ImageButton
{
//...
temp.setStyle("icon", "assets/lagoon.jpg");
//...
}
If we modified setStyle to accept pseudo states as a third parameter we
could do something like this:
private function _PseudoStatesTest_ImageButton1_i() :
com.flexcapacitor.controls.ImageButton
{
//...
temp.setStyle("icon", "assets/lagoon.jpg");
temp.setStyle("icon", "assets/lagoon_up_image.jpg", "up");
//...
}
We could also modify getStyle with a third parameter to get the value in a
different state:
var s:String = temp.getStyle("icon", "up"); //
assets/lagoon_up_image.jpg
Currently, there is no way to get the value of a style from a different
state with these methods. But if we are going to add pseudo states we might
as well support getting and setting document level state values in AS3 and
make pseudo state values a fourth option:
temp.getStyle("icon", "about", false); // get the value of icon in the
"about" document state
temp.getStyle("icon", "up", true); // get the value of icon in the
current target "up" pseudo state
temp.setStyle("icon", "assets/lagoon.jpg", "about", false); // set the
icon value in the about state
temp.setStyle("icon", "assets/lagoon_up_image.jpg", "up", true); // set
the icon value in the current target pseudo "up" state
So the compiler would write the correct setStyle syntax when it encountered
pseudo states and the setStyle method would handle creating the pseudo
states and conditions in the same way the CSS declarations are creating
them (see the generated controls|ImageButton:up code above) and the
setStyle method could create them at runtime without the compilers
generated code from the CSS.
On Mon, Mar 9, 2015 at 2:11 PM, Alex Harui <ah...@adobe.com> wrote:
> First of all, technically, you are sort of trying to do this:
>
> <s:Button>
> <s:skin>
> <s:ButtonSkin icon.up=“upImage.png” />
> </s:skin>
> </s:Button>
>
> The Button itself may not have an icon property, and the Button itself
> doesn’t have a set of states like “up”.
>
> So, setting the currentState on Button may not have any effect, and might
> not have an effect if the Skin itself doesn’t support such a state, or
> throw an exception if that state doesn’t exist. Thus, you are trying to
> skip a level of abstraction which can be tricky and I think makes the
> problem harder.
>
> I’m not saying it isn’t worth doing, just thinking about how hard it will
> be.
>
> CSS is interesting in that it doesn’t set a property per-se. It can be
> thought of as a filter on the DOM. It searches using Selector subjects
> and if it finds a match, applies the rules. The danger is that if you
> accidentally have the same subtree somewhere else in the DOM it also
> matches and changes. Pseudo-states are part of the filter/selection.
> There is no way to do inline pseudo styles in HTML markup either.
>
> -Alex
>
> On 3/8/15, 11:45 AM, "jude" <fl...@gmail.com> wrote:
>
> >Hmm. I don't have any problem with using the "icon.up" in the MXML skin.
> >I'm thinking of the occasion in the example.
> >
> >We could still declare the states property changes generated code as part
> >of the document except when we set a skin state we set the component
> >instance.currentState instead of currentState.
> >
> >Doesn't UIComponent have a states property? We could assign the state's
> >values when we assign the skin. The skin has a list of its states correct?
> >Sorry on mobile.
> >
> >We could have a different syntax for it:
> >
> >icon:up="upImage.png"
> >
> >icon::up="upImage.png"
> >
> >icon@up="upImage.png"
> >
> >icon#up="upImage.png"
> >
> >Not sure if these examples will show up. the problem with the first two is
> >that a colon + any character turns into emoticons. So posting examples
> >online and chat might get translated.
> >
> >I'll have to look at the code but when we have CSS that uses pseudo states
> >we use that same code when we encounter inline MXML pseudo state
> >syntax,"icon#up".
> >
> >On Saturday, March 7, 2015, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Interesting. I get why you would want that.
> >>
> >> States are declared as part of the document. So “icon.about” tells the
> >> compiler to set the icon when the MXML file changes currentState to
> >> “about”. The Button skin, if it were defined in MXML, would have the
> >>“up”
> >> state, not necessarily the MXML file that contains the Button. The
> >> generated code in the containing MXML doesn’t know anything about
> >>Button’s
> >> skin’s states since even the skin itself can be assigned at runtime or
> >>via
> >> CSS. Feels a bit like piercing an abstraction boundary, but I get that
> >> CSS lets you do it. Does it feel too unnatural to have to use icon.up
> >>in
> >> the Button’s skin?
> >>
> >> -Alex
> >>
> >> On 3/7/15, 9:34 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com
> >> <javascript:;>> wrote:
> >>
> >> >This sounds like a fantastic idea. It would be a bonus if we could get
> >> >the
> >> >same state names auto-complete feature to work in CSS as well.
> >> >
> >> >Thanks,
> >> >Om
> >> >On Mar 7, 2015 8:08 PM, "jude" <flexcapacitor@gmail.com
> <javascript:;>>
> >> wrote:
> >> >
> >> >> In CSS you can address certain states of a component using pseudo
> >>states
> >> >> (states) like so:
> >> >>
> >> >> s|Button#iconOnlyButton:up {
> >> >> icon: "assets/upImage.png";
> >> >> }
> >> >> s|Button#iconOnlyButton:over {
> >> >> icon: "assets/overImage.png";
> >> >> }
> >> >> s|Button#iconOnlyButton:down {
> >> >> icon: "assets/downImage.png";
> >> >> }
> >> >>
> >> >> But you can't do the same thing in MXML.
> >> >>
> >> >> You *can* address document level states in MXML like so:
> >> >>
> >> >> <s:Button icon="default.png" icon.about="about.png"/>
> >> >>
> >> >> <s:states>
> >> >> <s:State name="home" />
> >> >> <s:State name="gallery" />
> >> >> <s:State name="feedback" />
> >> >> </s:states>
> >> >>
> >> >> But that doesn't let you assign values to states of the component.
> >>This
> >> >> will throw an error:
> >> >>
> >> >> <s:Button icon="default.png" icon.up="about.png"/>
> >> >>
> >> >> While this CSS will not:
> >> >>
> >> >> s|Button#iconOnlyButton:up {
> >> >> icon: "about.png";
> >> >> }
> >> >>
> >> >> Is it possible to add support for inline pseudo states like we do
> >>with
> >> >>CSS?
> >> >> Does anyone else want this? How would we do it?
> >> >>
> >> >> Jude
> >> >>
> >>
> >>
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
First of all, technically, you are sort of trying to do this:
<s:Button>
<s:skin>
<s:ButtonSkin icon.up=“upImage.png” />
</s:skin>
</s:Button>
The Button itself may not have an icon property, and the Button itself
doesn’t have a set of states like “up”.
So, setting the currentState on Button may not have any effect, and might
not have an effect if the Skin itself doesn’t support such a state, or
throw an exception if that state doesn’t exist. Thus, you are trying to
skip a level of abstraction which can be tricky and I think makes the
problem harder.
I’m not saying it isn’t worth doing, just thinking about how hard it will
be.
CSS is interesting in that it doesn’t set a property per-se. It can be
thought of as a filter on the DOM. It searches using Selector subjects
and if it finds a match, applies the rules. The danger is that if you
accidentally have the same subtree somewhere else in the DOM it also
matches and changes. Pseudo-states are part of the filter/selection.
There is no way to do inline pseudo styles in HTML markup either.
-Alex
On 3/8/15, 11:45 AM, "jude" <fl...@gmail.com> wrote:
>Hmm. I don't have any problem with using the "icon.up" in the MXML skin.
>I'm thinking of the occasion in the example.
>
>We could still declare the states property changes generated code as part
>of the document except when we set a skin state we set the component
>instance.currentState instead of currentState.
>
>Doesn't UIComponent have a states property? We could assign the state's
>values when we assign the skin. The skin has a list of its states correct?
>Sorry on mobile.
>
>We could have a different syntax for it:
>
>icon:up="upImage.png"
>
>icon::up="upImage.png"
>
>icon@up="upImage.png"
>
>icon#up="upImage.png"
>
>Not sure if these examples will show up. the problem with the first two is
>that a colon + any character turns into emoticons. So posting examples
>online and chat might get translated.
>
>I'll have to look at the code but when we have CSS that uses pseudo states
>we use that same code when we encounter inline MXML pseudo state
>syntax,"icon#up".
>
>On Saturday, March 7, 2015, Alex Harui <ah...@adobe.com> wrote:
>
>> Interesting. I get why you would want that.
>>
>> States are declared as part of the document. So “icon.about” tells the
>> compiler to set the icon when the MXML file changes currentState to
>> “about”. The Button skin, if it were defined in MXML, would have the
>>“up”
>> state, not necessarily the MXML file that contains the Button. The
>> generated code in the containing MXML doesn’t know anything about
>>Button’s
>> skin’s states since even the skin itself can be assigned at runtime or
>>via
>> CSS. Feels a bit like piercing an abstraction boundary, but I get that
>> CSS lets you do it. Does it feel too unnatural to have to use icon.up
>>in
>> the Button’s skin?
>>
>> -Alex
>>
>> On 3/7/15, 9:34 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com
>> <javascript:;>> wrote:
>>
>> >This sounds like a fantastic idea. It would be a bonus if we could get
>> >the
>> >same state names auto-complete feature to work in CSS as well.
>> >
>> >Thanks,
>> >Om
>> >On Mar 7, 2015 8:08 PM, "jude" <flexcapacitor@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> In CSS you can address certain states of a component using pseudo
>>states
>> >> (states) like so:
>> >>
>> >> s|Button#iconOnlyButton:up {
>> >> icon: "assets/upImage.png";
>> >> }
>> >> s|Button#iconOnlyButton:over {
>> >> icon: "assets/overImage.png";
>> >> }
>> >> s|Button#iconOnlyButton:down {
>> >> icon: "assets/downImage.png";
>> >> }
>> >>
>> >> But you can't do the same thing in MXML.
>> >>
>> >> You *can* address document level states in MXML like so:
>> >>
>> >> <s:Button icon="default.png" icon.about="about.png"/>
>> >>
>> >> <s:states>
>> >> <s:State name="home" />
>> >> <s:State name="gallery" />
>> >> <s:State name="feedback" />
>> >> </s:states>
>> >>
>> >> But that doesn't let you assign values to states of the component.
>>This
>> >> will throw an error:
>> >>
>> >> <s:Button icon="default.png" icon.up="about.png"/>
>> >>
>> >> While this CSS will not:
>> >>
>> >> s|Button#iconOnlyButton:up {
>> >> icon: "about.png";
>> >> }
>> >>
>> >> Is it possible to add support for inline pseudo states like we do
>>with
>> >>CSS?
>> >> Does anyone else want this? How would we do it?
>> >>
>> >> Jude
>> >>
>>
>>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by jude <fl...@gmail.com>.
Hmm. I don't have any problem with using the "icon.up" in the MXML skin.
I'm thinking of the occasion in the example.
We could still declare the states property changes generated code as part
of the document except when we set a skin state we set the component
instance.currentState instead of currentState.
Doesn't UIComponent have a states property? We could assign the state's
values when we assign the skin. The skin has a list of its states correct?
Sorry on mobile.
We could have a different syntax for it:
icon:up="upImage.png"
icon::up="upImage.png"
icon@up="upImage.png"
icon#up="upImage.png"
Not sure if these examples will show up. the problem with the first two is
that a colon + any character turns into emoticons. So posting examples
online and chat might get translated.
I'll have to look at the code but when we have CSS that uses pseudo states
we use that same code when we encounter inline MXML pseudo state
syntax,"icon#up".
On Saturday, March 7, 2015, Alex Harui <ah...@adobe.com> wrote:
> Interesting. I get why you would want that.
>
> States are declared as part of the document. So “icon.about” tells the
> compiler to set the icon when the MXML file changes currentState to
> “about”. The Button skin, if it were defined in MXML, would have the “up”
> state, not necessarily the MXML file that contains the Button. The
> generated code in the containing MXML doesn’t know anything about Button’s
> skin’s states since even the skin itself can be assigned at runtime or via
> CSS. Feels a bit like piercing an abstraction boundary, but I get that
> CSS lets you do it. Does it feel too unnatural to have to use icon.up in
> the Button’s skin?
>
> -Alex
>
> On 3/7/15, 9:34 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com
> <javascript:;>> wrote:
>
> >This sounds like a fantastic idea. It would be a bonus if we could get
> >the
> >same state names auto-complete feature to work in CSS as well.
> >
> >Thanks,
> >Om
> >On Mar 7, 2015 8:08 PM, "jude" <flexcapacitor@gmail.com <javascript:;>>
> wrote:
> >
> >> In CSS you can address certain states of a component using pseudo states
> >> (states) like so:
> >>
> >> s|Button#iconOnlyButton:up {
> >> icon: "assets/upImage.png";
> >> }
> >> s|Button#iconOnlyButton:over {
> >> icon: "assets/overImage.png";
> >> }
> >> s|Button#iconOnlyButton:down {
> >> icon: "assets/downImage.png";
> >> }
> >>
> >> But you can't do the same thing in MXML.
> >>
> >> You *can* address document level states in MXML like so:
> >>
> >> <s:Button icon="default.png" icon.about="about.png"/>
> >>
> >> <s:states>
> >> <s:State name="home" />
> >> <s:State name="gallery" />
> >> <s:State name="feedback" />
> >> </s:states>
> >>
> >> But that doesn't let you assign values to states of the component. This
> >> will throw an error:
> >>
> >> <s:Button icon="default.png" icon.up="about.png"/>
> >>
> >> While this CSS will not:
> >>
> >> s|Button#iconOnlyButton:up {
> >> icon: "about.png";
> >> }
> >>
> >> Is it possible to add support for inline pseudo states like we do with
> >>CSS?
> >> Does anyone else want this? How would we do it?
> >>
> >> Jude
> >>
>
>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by Alex Harui <ah...@adobe.com>.
Interesting. I get why you would want that.
States are declared as part of the document. So “icon.about” tells the
compiler to set the icon when the MXML file changes currentState to
“about”. The Button skin, if it were defined in MXML, would have the “up”
state, not necessarily the MXML file that contains the Button. The
generated code in the containing MXML doesn’t know anything about Button’s
skin’s states since even the skin itself can be assigned at runtime or via
CSS. Feels a bit like piercing an abstraction boundary, but I get that
CSS lets you do it. Does it feel too unnatural to have to use icon.up in
the Button’s skin?
-Alex
On 3/7/15, 9:34 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>This sounds like a fantastic idea. It would be a bonus if we could get
>the
>same state names auto-complete feature to work in CSS as well.
>
>Thanks,
>Om
>On Mar 7, 2015 8:08 PM, "jude" <fl...@gmail.com> wrote:
>
>> In CSS you can address certain states of a component using pseudo states
>> (states) like so:
>>
>> s|Button#iconOnlyButton:up {
>> icon: "assets/upImage.png";
>> }
>> s|Button#iconOnlyButton:over {
>> icon: "assets/overImage.png";
>> }
>> s|Button#iconOnlyButton:down {
>> icon: "assets/downImage.png";
>> }
>>
>> But you can't do the same thing in MXML.
>>
>> You *can* address document level states in MXML like so:
>>
>> <s:Button icon="default.png" icon.about="about.png"/>
>>
>> <s:states>
>> <s:State name="home" />
>> <s:State name="gallery" />
>> <s:State name="feedback" />
>> </s:states>
>>
>> But that doesn't let you assign values to states of the component. This
>> will throw an error:
>>
>> <s:Button icon="default.png" icon.up="about.png"/>
>>
>> While this CSS will not:
>>
>> s|Button#iconOnlyButton:up {
>> icon: "about.png";
>> }
>>
>> Is it possible to add support for inline pseudo states like we do with
>>CSS?
>> Does anyone else want this? How would we do it?
>>
>> Jude
>>
Re: [DISCUSSION] MXML pseudo states suggestion
Posted by OmPrakash Muppirala <bi...@gmail.com>.
This sounds like a fantastic idea. It would be a bonus if we could get the
same state names auto-complete feature to work in CSS as well.
Thanks,
Om
On Mar 7, 2015 8:08 PM, "jude" <fl...@gmail.com> wrote:
> In CSS you can address certain states of a component using pseudo states
> (states) like so:
>
> s|Button#iconOnlyButton:up {
> icon: "assets/upImage.png";
> }
> s|Button#iconOnlyButton:over {
> icon: "assets/overImage.png";
> }
> s|Button#iconOnlyButton:down {
> icon: "assets/downImage.png";
> }
>
> But you can't do the same thing in MXML.
>
> You *can* address document level states in MXML like so:
>
> <s:Button icon="default.png" icon.about="about.png"/>
>
> <s:states>
> <s:State name="home" />
> <s:State name="gallery" />
> <s:State name="feedback" />
> </s:states>
>
> But that doesn't let you assign values to states of the component. This
> will throw an error:
>
> <s:Button icon="default.png" icon.up="about.png"/>
>
> While this CSS will not:
>
> s|Button#iconOnlyButton:up {
> icon: "about.png";
> }
>
> Is it possible to add support for inline pseudo states like we do with CSS?
> Does anyone else want this? How would we do it?
>
> Jude
>