Re: Incorrect descendent CSS output

[Carlos Rovira]

I must say I don't remember exactly. I did many test and research and
compare with what others trying to solve the same in the internet without
using a concrete library that at that time I think we want to avoid. So you
can try to compile with and without and use a compare tool to see what you
get and maybe that show the intention of the regex . Maybe it make some
little improvement, but if it remove something, better remove it.

2018-06-06 14:48 GMT+02:00 Harbs :

> I understand, but I’m trying to understand what the logic of that line of
> code was. What was it trying to do?
>
> I could simply remove the line, but if it’s serving a function, we should
> probably fix the RegEx instead.
>
> Thanks,
> Harbs
>
> > On Jun 6, 2018, at 3:36 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > that was a simple attempt to minify css code, if that line is not working
> > you can comment it, and we'll be improving the minifying method.
> >
> > thanks
> >
> >
> >
> > 2018-06-06 14:27 GMT+02:00 Harbs :
> >
> >> It’s this code in minifyCSSString:
> >>cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
> >>
> >> Why is that code there?
> >>
> >> Harbs
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Incorrect descendent CSS output

[Harbs]

I understand, but I’m trying to understand what the logic of that line of code 
was. What was it trying to do?

I could simply remove the line, but if it’s serving a function, we should 
probably fix the RegEx instead.

Thanks,
Harbs

> On Jun 6, 2018, at 3:36 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> that was a simple attempt to minify css code, if that line is not working
> you can comment it, and we'll be improving the minifying method.
> 
> thanks
> 
> 
> 
> 2018-06-06 14:27 GMT+02:00 Harbs :
> 
>> It’s this code in minifyCSSString:
>>cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
>> 
>> Why is that code there?
>> 
>> Harbs

Re: Incorrect descendent CSS output

[Carlos Rovira]

Hi Harbs,

that was a simple attempt to minify css code, if that line is not working
you can comment it, and we'll be improving the minifying method.

thanks



2018-06-06 14:27 GMT+02:00 Harbs :

> It’s this code in minifyCSSString:
> cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
>
> Why is that code there?
>
> Harbs
>
> > On Jun 6, 2018, at 3:21 PM, Harbs  wrote:
> >
> > I found another problem.
> >
> > The following CSS is the correct compiled results in the debug css:
> >
> >
> > .toggleTextButton.selected#subscriptButton {
> >cursor: pointer;
> >background-color: transparent;
> >outline: none;
> >background-image: url("assets/images/icons/
> subscript_selected.svg");
> >border-style: hidden;
> > }
> >
> >
> > .toggleTextButton#subscriptButton {
> >cursor: pointer;
> >background-color: transparent;
> >outline: none;
> >background-image: url("assets/images/icons/subscript.svg");
> >border-style: hidden;
> > }
> >
> > Somehow in the release version, the CSS becomes the following: The class
> selector before the subscriptButton id selector gets lost after the dot.
> Any idea what might be causing it?
> >
> > .toggleTextButton.#subscriptButton{cursor:pointer;background-color:
> transparent;outline:none;background-image:url("assets/
> images/icons/subscript_selected.svg");border-style:
> hidden;}.#subscriptButton{cursor:pointer;background-
> color:transparent;outline:none;background-image:url("
> assets/images/icons/subscript.svg");border-style:hidden;}
> >
> >> On Jun 6, 2018, at 2:24 AM, Alex Harui 
> wrote:
> >>
> >> If the namespace prefixes are stored in the selector, then when
> deciding whether to keepRules, we should check the prefix and if it is null
> and the default namespace is xhtml, then we can use a fully qualified name
> in the comparison.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 6/5/18, 3:09 PM, "Harbs"  wrote:
> >>
> >>   Hmm. I wonder if CSSSemanticAnalyzer.resolveSelectors could stuff
> the selector namespace into the ICSSSelector. It seems to be looping
> through them anyway. ICSSSeelctor would need a new property for this.) Is
> CSSSemanticAnalyzer.resolveSelectors called before
> JSCSSCompilationSession.cssRuleToString?
> >>
> >>> On Jun 6, 2018, at 1:01 AM, Harbs  wrote:
> >>>
> >>> I’m not using menu, and it’s pretty doubtful anyone else is using it
> yet either, so yeah, it’s probably safe to remove it temporarily. Not sure
> which other elements might cause problems.
> >>>
> >>> Another one which we really should fix is Button (because Button
> component styling effects every button element in the app even if it’s not
> a “Button” component). That’s something I’ve struggled with... But removing
> that one is going to cause problems…
> >>>
> >>> I did notice that CSSSemanticAnalyzer is checking for the xhtml
> namespace, but it’s only doing so for the default namespace. ICSSSelector
> seems to have a prefix, but no namespace (unless I’m missing something).
> >>>
> >>> Harbs
> >>>
>  On Jun 6, 2018, at 12:51 AM, Alex Harui 
> wrote:
> 
>  The data structure seems to have a slot to hold a namespace.  I think
> there is code somewhere that checks the namespace to avoid the outputting
> some error, but it may not be storing it.
> 
>  The short term solution may be to remove menu from the list of
> htmlelements.  Does anybody actually use it?
> 
>  HTH,
>  -Alex
> 
>  On 6/5/18, 2:46 PM, "Harbs"  wrote:
> 
>  I think it’s line 189. It checks if the lowercase string matches.
> Only if that check fails does it enter the logic to figure out where to
> insert the dot. I’m really not sure how to fix this though… :-(
> 
>  We’d need menu{} to stay menu{} for html elements, but become .menu{}
> for other component types. FWIW, I think all selectors are case insensitive.
> 
>  Harbs
> 
> > On Jun 6, 2018, at 12:32 AM, Alex Harui 
> wrote:
> >
> >
> >
> > On 6/5/18, 2:29 PM, "Harbs"  wrote:
> >
> > Done.
> >
> > That does seem to fix the problem.
> >
> > Of course, things like .Menu{} (for org.apache.royale.html.Menu) now
> became Menu{}. Considering that Menu is actually a List which is a div and
> not a menu element, this will break any styling applied to Menu components…
> There might be others. Not sure what the easiest way to solve this problem
> is.
> >
> > I'm not sure what that would be the case.  Maybe debug through it or
> add System.out.println.  I think ArrayList.contains() is case sensitive, so
> I'm surprised that "Menu" is matching "menu".
> >
> > Or am I not understanding your point?
> > -Alex
> >
> >
> 
> 
> 
> >>>
> >>
> >>
> >>
> >
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Incorrect descendent CSS output

[Harbs]

It’s this code in minifyCSSString:
cssString = cssString.replaceAll("[a-zA-Z]+#", "#");

Why is that code there?

Harbs

> On Jun 6, 2018, at 3:21 PM, Harbs  wrote:
> 
> I found another problem.
> 
> The following CSS is the correct compiled results in the debug css:
> 
> 
> .toggleTextButton.selected#subscriptButton {
>cursor: pointer;
>background-color: transparent;
>outline: none;
>background-image: url("assets/images/icons/subscript_selected.svg");
>border-style: hidden;
> }
> 
> 
> .toggleTextButton#subscriptButton {
>cursor: pointer;
>background-color: transparent;
>outline: none;
>background-image: url("assets/images/icons/subscript.svg");
>border-style: hidden;
> }
> 
> Somehow in the release version, the CSS becomes the following: The class 
> selector before the subscriptButton id selector gets lost after the dot. Any 
> idea what might be causing it?
> 
> .toggleTextButton.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript_selected.svg");border-style:hidden;}.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript.svg");border-style:hidden;}
> 
>> On Jun 6, 2018, at 2:24 AM, Alex Harui  wrote:
>> 
>> If the namespace prefixes are stored in the selector, then when deciding 
>> whether to keepRules, we should check the prefix and if it is null and the 
>> default namespace is xhtml, then we can use a fully qualified name in the 
>> comparison.
>> 
>> HTH,
>> -Alex
>> 
>> On 6/5/18, 3:09 PM, "Harbs"  wrote:
>> 
>>   Hmm. I wonder if CSSSemanticAnalyzer.resolveSelectors could stuff the 
>> selector namespace into the ICSSSelector. It seems to be looping through 
>> them anyway. ICSSSeelctor would need a new property for this.) Is 
>> CSSSemanticAnalyzer.resolveSelectors called before 
>> JSCSSCompilationSession.cssRuleToString?
>> 
>>> On Jun 6, 2018, at 1:01 AM, Harbs  wrote:
>>> 
>>> I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
>>> either, so yeah, it’s probably safe to remove it temporarily. Not sure 
>>> which other elements might cause problems.
>>> 
>>> Another one which we really should fix is Button (because Button component 
>>> styling effects every button element in the app even if it’s not a “Button” 
>>> component). That’s something I’ve struggled with... But removing that one 
>>> is going to cause problems…
>>> 
>>> I did notice that CSSSemanticAnalyzer is checking for the xhtml namespace, 
>>> but it’s only doing so for the default namespace. ICSSSelector seems to 
>>> have a prefix, but no namespace (unless I’m missing something).
>>> 
>>> Harbs
>>> 
 On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
 
 The data structure seems to have a slot to hold a namespace.  I think 
 there is code somewhere that checks the namespace to avoid the outputting 
 some error, but it may not be storing it.
 
 The short term solution may be to remove menu from the list of 
 htmlelements.  Does anybody actually use it?
 
 HTH,
 -Alex
 
 On 6/5/18, 2:46 PM, "Harbs"  wrote:
 
 I think it’s line 189. It checks if the lowercase string matches. Only if 
 that check fails does it enter the logic to figure out where to insert the 
 dot. I’m really not sure how to fix this though… :-(
 
 We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
 other component types. FWIW, I think all selectors are case insensitive.
 
 Harbs
 
> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 2:29 PM, "Harbs"  wrote:
> 
> Done.
> 
> That does seem to fix the problem.
> 
> Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
> became Menu{}. Considering that Menu is actually a List which is a div 
> and not a menu element, this will break any styling applied to Menu 
> components… There might be others. Not sure what the easiest way to solve 
> this problem is.
> 
> I'm not sure what that would be the case.  Maybe debug through it or add 
> System.out.println.  I think ArrayList.contains() is case sensitive, so 
> I'm surprised that "Menu" is matching "menu".
> 
> Or am I not understanding your point?
> -Alex
> 
> 
 
 
 
>>> 
>> 
>> 
>> 
> 

Re: Incorrect descendent CSS output

[Harbs]

I found another problem.

The following CSS is the correct compiled results in the debug css:


.toggleTextButton.selected#subscriptButton {
cursor: pointer;
background-color: transparent;
outline: none;
background-image: url("assets/images/icons/subscript_selected.svg");
border-style: hidden;
}


.toggleTextButton#subscriptButton {
cursor: pointer;
background-color: transparent;
outline: none;
background-image: url("assets/images/icons/subscript.svg");
border-style: hidden;
}

Somehow in the release version, the CSS becomes the following: The class 
selector before the subscriptButton id selector gets lost after the dot. Any 
idea what might be causing it?

.toggleTextButton.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript_selected.svg");border-style:hidden;}.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript.svg");border-style:hidden;}

> On Jun 6, 2018, at 2:24 AM, Alex Harui  wrote:
> 
> If the namespace prefixes are stored in the selector, then when deciding 
> whether to keepRules, we should check the prefix and if it is null and the 
> default namespace is xhtml, then we can use a fully qualified name in the 
> comparison.
> 
> HTH,
> -Alex
> 
> On 6/5/18, 3:09 PM, "Harbs"  wrote:
> 
>Hmm. I wonder if CSSSemanticAnalyzer.resolveSelectors could stuff the 
> selector namespace into the ICSSSelector. It seems to be looping through them 
> anyway. ICSSSeelctor would need a new property for this.) Is 
> CSSSemanticAnalyzer.resolveSelectors called before 
> JSCSSCompilationSession.cssRuleToString?
> 
>> On Jun 6, 2018, at 1:01 AM, Harbs  wrote:
>> 
>> I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
>> either, so yeah, it’s probably safe to remove it temporarily. Not sure which 
>> other elements might cause problems.
>> 
>> Another one which we really should fix is Button (because Button component 
>> styling effects every button element in the app even if it’s not a “Button” 
>> component). That’s something I’ve struggled with... But removing that one is 
>> going to cause problems…
>> 
>> I did notice that CSSSemanticAnalyzer is checking for the xhtml namespace, 
>> but it’s only doing so for the default namespace. ICSSSelector seems to have 
>> a prefix, but no namespace (unless I’m missing something).
>> 
>> Harbs
>> 
>>> On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
>>> 
>>> The data structure seems to have a slot to hold a namespace.  I think there 
>>> is code somewhere that checks the namespace to avoid the outputting some 
>>> error, but it may not be storing it.
>>> 
>>> The short term solution may be to remove menu from the list of 
>>> htmlelements.  Does anybody actually use it?
>>> 
>>> HTH,
>>> -Alex
>>> 
>>> On 6/5/18, 2:46 PM, "Harbs"  wrote:
>>> 
>>>  I think it’s line 189. It checks if the lowercase string matches. Only if 
>>> that check fails does it enter the logic to figure out where to insert the 
>>> dot. I’m really not sure how to fix this though… :-(
>>> 
>>>  We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
>>> other component types. FWIW, I think all selectors are case insensitive.
>>> 
>>>  Harbs
>>> 
 On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
 
 
 
 On 6/5/18, 2:29 PM, "Harbs"  wrote:
 
 Done.
 
 That does seem to fix the problem.
 
 Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
 became Menu{}. Considering that Menu is actually a List which is a div and 
 not a menu element, this will break any styling applied to Menu 
 components… There might be others. Not sure what the easiest way to solve 
 this problem is.
 
 I'm not sure what that would be the case.  Maybe debug through it or add 
 System.out.println.  I think ArrayList.contains() is case sensitive, so 
 I'm surprised that "Menu" is matching "menu".
 
 Or am I not understanding your point?
 -Alex
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

Re: Incorrect descendent CSS output

[Alex Harui]

If the namespace prefixes are stored in the selector, then when deciding 
whether to keepRules, we should check the prefix and if it is null and the 
default namespace is xhtml, then we can use a fully qualified name in the 
comparison.

HTH,
-Alex

On 6/5/18, 3:09 PM, "Harbs"  wrote:

Hmm. I wonder if CSSSemanticAnalyzer.resolveSelectors could stuff the 
selector namespace into the ICSSSelector. It seems to be looping through them 
anyway. ICSSSeelctor would need a new property for this.) Is 
CSSSemanticAnalyzer.resolveSelectors called before 
JSCSSCompilationSession.cssRuleToString?

> On Jun 6, 2018, at 1:01 AM, Harbs  wrote:
> 
> I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
either, so yeah, it’s probably safe to remove it temporarily. Not sure which 
other elements might cause problems.
> 
> Another one which we really should fix is Button (because Button 
component styling effects every button element in the app even if it’s not a 
“Button” component). That’s something I’ve struggled with... But removing that 
one is going to cause problems…
> 
> I did notice that CSSSemanticAnalyzer is checking for the xhtml 
namespace, but it’s only doing so for the default namespace. ICSSSelector seems 
to have a prefix, but no namespace (unless I’m missing something).
> 
> Harbs
> 
>> On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
>> 
>> The data structure seems to have a slot to hold a namespace.  I think 
there is code somewhere that checks the namespace to avoid the outputting some 
error, but it may not be storing it.
>> 
>> The short term solution may be to remove menu from the list of 
htmlelements.  Does anybody actually use it?
>> 
>> HTH,
>> -Alex
>> 
>> On 6/5/18, 2:46 PM, "Harbs"  wrote:
>> 
>>   I think it’s line 189. It checks if the lowercase string matches. Only 
if that check fails does it enter the logic to figure out where to insert the 
dot. I’m really not sure how to fix this though… :-(
>> 
>>   We’d need menu{} to stay menu{} for html elements, but become .menu{} 
for other component types. FWIW, I think all selectors are case insensitive.
>> 
>>   Harbs
>> 
>>> On Jun 6, 2018, at 12:32 AM, Alex Harui  
wrote:
>>> 
>>> 
>>> 
>>> On 6/5/18, 2:29 PM, "Harbs"  wrote:
>>> 
>>>  Done.
>>> 
>>>  That does seem to fix the problem.
>>> 
>>>  Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
became Menu{}. Considering that Menu is actually a List which is a div and not 
a menu element, this will break any styling applied to Menu components… There 
might be others. Not sure what the easiest way to solve this problem is.
>>> 
>>> I'm not sure what that would be the case.  Maybe debug through it or 
add System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
surprised that "Menu" is matching "menu".
>>> 
>>> Or am I not understanding your point?
>>> -Alex
>>> 
>>> 
>> 
>> 
>> 
> 

Re: Incorrect descendent CSS output

[Harbs]

Hmm. I wonder if CSSSemanticAnalyzer.resolveSelectors could stuff the selector 
namespace into the ICSSSelector. It seems to be looping through them anyway. 
ICSSSeelctor would need a new property for this.) Is 
CSSSemanticAnalyzer.resolveSelectors called before 
JSCSSCompilationSession.cssRuleToString?

> On Jun 6, 2018, at 1:01 AM, Harbs  wrote:
> 
> I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
> either, so yeah, it’s probably safe to remove it temporarily. Not sure which 
> other elements might cause problems.
> 
> Another one which we really should fix is Button (because Button component 
> styling effects every button element in the app even if it’s not a “Button” 
> component). That’s something I’ve struggled with... But removing that one is 
> going to cause problems…
> 
> I did notice that CSSSemanticAnalyzer is checking for the xhtml namespace, 
> but it’s only doing so for the default namespace. ICSSSelector seems to have 
> a prefix, but no namespace (unless I’m missing something).
> 
> Harbs
> 
>> On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
>> 
>> The data structure seems to have a slot to hold a namespace.  I think there 
>> is code somewhere that checks the namespace to avoid the outputting some 
>> error, but it may not be storing it.
>> 
>> The short term solution may be to remove menu from the list of htmlelements. 
>>  Does anybody actually use it?
>> 
>> HTH,
>> -Alex
>> 
>> On 6/5/18, 2:46 PM, "Harbs"  wrote:
>> 
>>   I think it’s line 189. It checks if the lowercase string matches. Only if 
>> that check fails does it enter the logic to figure out where to insert the 
>> dot. I’m really not sure how to fix this though… :-(
>> 
>>   We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
>> other component types. FWIW, I think all selectors are case insensitive.
>> 
>>   Harbs
>> 
>>> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
>>> 
>>> 
>>> 
>>> On 6/5/18, 2:29 PM, "Harbs"  wrote:
>>> 
>>>  Done.
>>> 
>>>  That does seem to fix the problem.
>>> 
>>>  Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
>>> became Menu{}. Considering that Menu is actually a List which is a div and 
>>> not a menu element, this will break any styling applied to Menu components… 
>>> There might be others. Not sure what the easiest way to solve this problem 
>>> is.
>>> 
>>> I'm not sure what that would be the case.  Maybe debug through it or add 
>>> System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
>>> surprised that "Menu" is matching "menu".
>>> 
>>> Or am I not understanding your point?
>>> -Alex
>>> 
>>> 
>> 
>> 
>> 
> 

Re: Incorrect descendent CSS output

[Harbs]

I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
either, so yeah, it’s probably safe to remove it temporarily. Not sure which 
other elements might cause problems.

Another one which we really should fix is Button (because Button component 
styling effects every button element in the app even if it’s not a “Button” 
component). That’s something I’ve struggled with... But removing that one is 
going to cause problems…

I did notice that CSSSemanticAnalyzer is checking for the xhtml namespace, but 
it’s only doing so for the default namespace. ICSSSelector seems to have a 
prefix, but no namespace (unless I’m missing something).

Harbs

> On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
> 
> The data structure seems to have a slot to hold a namespace.  I think there 
> is code somewhere that checks the namespace to avoid the outputting some 
> error, but it may not be storing it.
> 
> The short term solution may be to remove menu from the list of htmlelements.  
> Does anybody actually use it?
> 
> HTH,
> -Alex
> 
> On 6/5/18, 2:46 PM, "Harbs"  wrote:
> 
>I think it’s line 189. It checks if the lowercase string matches. Only if 
> that check fails does it enter the logic to figure out where to insert the 
> dot. I’m really not sure how to fix this though… :-(
> 
>We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
> other component types. FWIW, I think all selectors are case insensitive.
> 
>Harbs
> 
>> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 6/5/18, 2:29 PM, "Harbs"  wrote:
>> 
>>   Done.
>> 
>>   That does seem to fix the problem.
>> 
>>   Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
>> became Menu{}. Considering that Menu is actually a List which is a div and 
>> not a menu element, this will break any styling applied to Menu components… 
>> There might be others. Not sure what the easiest way to solve this problem 
>> is.
>> 
>> I'm not sure what that would be the case.  Maybe debug through it or add 
>> System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
>> surprised that "Menu" is matching "menu".
>> 
>> Or am I not understanding your point?
>> -Alex
>> 
>> 
> 
> 
> 

Re: Incorrect descendent CSS output

[Alex Harui]

The data structure seems to have a slot to hold a namespace.  I think there is 
code somewhere that checks the namespace to avoid the outputting some error, 
but it may not be storing it.

The short term solution may be to remove menu from the list of htmlelements.  
Does anybody actually use it?

HTH,
-Alex

On 6/5/18, 2:46 PM, "Harbs"  wrote:

I think it’s line 189. It checks if the lowercase string matches. Only if 
that check fails does it enter the logic to figure out where to insert the dot. 
I’m really not sure how to fix this though… :-(

We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
other component types. FWIW, I think all selectors are case insensitive.

Harbs

> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 2:29 PM, "Harbs"  wrote:
> 
>Done.
> 
>That does seem to fix the problem.
> 
>Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
became Menu{}. Considering that Menu is actually a List which is a div and not 
a menu element, this will break any styling applied to Menu components… There 
might be others. Not sure what the easiest way to solve this problem is.
> 
> I'm not sure what that would be the case.  Maybe debug through it or add 
System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
surprised that "Menu" is matching "menu".
> 
> Or am I not understanding your point?
> -Alex
> 
> 

Re: Incorrect descendent CSS output

[Harbs]

I think it’s line 189. It checks if the lowercase string matches. Only if that 
check fails does it enter the logic to figure out where to insert the dot. I’m 
really not sure how to fix this though… :-(

We’d need menu{} to stay menu{} for html elements, but become .menu{} for other 
component types. FWIW, I think all selectors are case insensitive.

Harbs

> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 2:29 PM, "Harbs"  wrote:
> 
>Done.
> 
>That does seem to fix the problem.
> 
>Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
> became Menu{}. Considering that Menu is actually a List which is a div and 
> not a menu element, this will break any styling applied to Menu components… 
> There might be others. Not sure what the easiest way to solve this problem is.
> 
> I'm not sure what that would be the case.  Maybe debug through it or add 
> System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
> surprised that "Menu" is matching "menu".
> 
> Or am I not understanding your point?
> -Alex
> 
> 

Re: Incorrect descendent CSS output

[Alex Harui]

On 6/5/18, 2:29 PM, "Harbs"  wrote:

Done.

That does seem to fix the problem.

Of course, things like .Menu{} (for org.apache.royale.html.Menu) now became 
Menu{}. Considering that Menu is actually a List which is a div and not a menu 
element, this will break any styling applied to Menu components… There might be 
others. Not sure what the easiest way to solve this problem is.

I'm not sure what that would be the case.  Maybe debug through it or add 
System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
surprised that "Menu" is matching "menu".

Or am I not understanding your point?
-Alex

Re: Incorrect descendent CSS output

[Harbs]

Done.

That does seem to fix the problem.

Of course, things like .Menu{} (for org.apache.royale.html.Menu) now became 
Menu{}. Considering that Menu is actually a List which is a div and not a menu 
element, this will break any styling applied to Menu components… There might be 
others. Not sure what the easiest way to solve this problem is.

I’m pretty sure we also still have to deal with avoiding component conflicts.

So, my problem is now working, but we’re not out of the woods… ;-)

Harbs

> On Jun 6, 2018, at 12:08 AM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 2:01 PM, "Harbs"  wrote:
> 
>OK. And that will only work for the html namespace?
> 
> Don’t know for sure.  It appears that the namespace is not retained.  So I 
> think if you add a component to Jewel call "h4" its type selector may be in 
> all output.  We might need to fix that, but there are probably bigger fish to 
> fry.
> 
> HTH,
> -Alex
> 
>> On Jun 5, 2018, at 11:57 PM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 6/5/18, 12:24 PM, "Harbs"  wrote:
>> 
>>   It doesn’t look like the fix helped.
>> 
>>   The following selectors are still being stripped out. I did not understand 
>> how the commit depends on namespaces. We should keep *all* selectors for 
>> generic HTML. 
>> 
>> Please add *all* selectors to htmlElementNames in 
>> JSCSSCompilationSession.java
>> 
>> Thanks,
>> -Alex
>> 
> 
> 
> 

Re: Incorrect descendent CSS output

[Alex Harui]

On 6/5/18, 2:01 PM, "Harbs"  wrote:

OK. And that will only work for the html namespace?

Don’t know for sure.  It appears that the namespace is not retained.  So I 
think if you add a component to Jewel call "h4" its type selector may be in all 
output.  We might need to fix that, but there are probably bigger fish to fry.

HTH,
-Alex

> On Jun 5, 2018, at 11:57 PM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 12:24 PM, "Harbs"  wrote:
> 
>It doesn’t look like the fix helped.
> 
>The following selectors are still being stripped out. I did not 
understand how the commit depends on namespaces. We should keep *all* selectors 
for generic HTML. 
> 
> Please add *all* selectors to htmlElementNames in 
JSCSSCompilationSession.java
> 
> Thanks,
> -Alex
> 

Re: Incorrect descendent CSS output

[Harbs]

OK. And that will only work for the html namespace?

> On Jun 5, 2018, at 11:57 PM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 12:24 PM, "Harbs"  wrote:
> 
>It doesn’t look like the fix helped.
> 
>The following selectors are still being stripped out. I did not understand 
> how the commit depends on namespaces. We should keep *all* selectors for 
> generic HTML. 
> 
> Please add *all* selectors to htmlElementNames in JSCSSCompilationSession.java
> 
> Thanks,
> -Alex
> 

Re: Incorrect descendent CSS output

[Alex Harui]

On 6/5/18, 12:24 PM, "Harbs"  wrote:

It doesn’t look like the fix helped.

The following selectors are still being stripped out. I did not understand 
how the commit depends on namespaces. We should keep *all* selectors for 
generic HTML. 

Please add *all* selectors to htmlElementNames in JSCSSCompilationSession.java

Thanks,
-Alex

Re: Incorrect descendent CSS output

[Harbs]

That one snuck in by mistake. It’s not being stripped out…

> On Jun 5, 2018, at 10:24 PM, Harbs  wrote:
> 
>  .tab__content > li .content__wrapper

Re: Incorrect descendent CSS output

[Harbs]

It doesn’t look like the fix helped.

The following selectors are still being stripped out. I did not understand how 
the commit depends on namespaces. We should keep *all* selectors for generic 
HTML. The way that’s currently declared is by using the “http :// www .w3 
.org/1999/xhtml” namespace.

.tabs > li {
transition-duration: .1s;
display: table-cell;
list-style: none;
text-align: center;
/* padding: 0px 20px 25px 20px; */
position: relative;
overflow: hidden;
cursor: pointer;
color: white; 
z-index: 1;
}
.tabs > li:before {
z-index: -1;
position: absolute;
content: "";
width: 100%;
height: 120%;
top: 0;
left: 0;
background-color: rgba(255, 255, 255, 0.3);
-webkit-transform: translateY(100%);
transform: translateY(100%);
transition-duration: .1s;
border-radius: 5px 5px 0 0;
}
.tabs > li:hover:before {
-webkit-transform: translateY(70%);
transform: translateY(70%);
}
.tabs > li.active {
color:#00;
/* color: #50555a; */
}
.tabs > li.active:before {
transition-duration: .1s;
background-color: #f3f3f3;
z-index: -1;
-webkit-transform: translateY(0);
transform: translateY(0);
}

.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
.tab__content > li .content__wrapper {
/*text-align: left;*/
border-radius: 5px;
width: calc(100% - 10px);
/* padding: 45px 40px 40px 40px; */
padding-left: 10px;
/* background-color: white; */
}
.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
> On Jun 5, 2018, at 7:56 PM, Alex Harui  wrote:
> 
> Good catch.  I pushed a fix that will fix that and hopefully not drag other 
> selectors back in.
> 
> -Alex
> 
> On 6/4/18, 9:48 PM, "Harbs"  wrote:
> 
>Thanks.
> 
>I just observed a new problem. I have not pulled in your changes, so I 
> don’t know if it’s fixed, but it used to work correctly.
> 
>Much of the following css is now being stripped out.
> 
>CSS in the 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0
>  
> 
>  namespace should always be left in.
> 
>@namespace 
> "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0;;
>.printui_app .PUITabContainer .tabs {
>display: table;
>table-layout: fixed;
>width: 100%;
>transform: translateY(5px);
>padding-left:0px;
>background-color: #4d4d4d;
>margin-top:0px;
>}
>.tabs > li {
>transition-duration: .1s;
>display: table-cell;
>list-style: none;
>text-align: center;
>/* padding: 0px 20px 25px 20px; */
>position: relative;
>overflow: hidden;
>cursor: pointer;
>color: white; 
>z-index: 1;
>}
>.tabs > li:before {
>z-index: -1;
>position: absolute;
>content: "";
>width: 100%;
>height: 120%;
>top: 0;
>left: 0;
>background-color: rgba(255, 255, 255, 0.3);
>-webkit-transform: translateY(100%);
>transform: translateY(100%);
>transition-duration: .1s;
>border-radius: 5px 5px 0 0;
>}
>.tabs > li:hover:before {
>-webkit-transform: translateY(70%);
>transform: translateY(70%);
>}
>.tabs > li.active 

Re: Incorrect descendent CSS output

[Alex Harui]

Good catch.  I pushed a fix that will fix that and hopefully not drag other 
selectors back in.

-Alex

On 6/4/18, 9:48 PM, "Harbs"  wrote:

Thanks.

I just observed a new problem. I have not pulled in your changes, so I 
don’t know if it’s fixed, but it used to work correctly.

Much of the following css is now being stripped out.

CSS in the 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0
 

 namespace should always be left in.

@namespace 
"https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0;;
.printui_app .PUITabContainer .tabs {
display: table;
table-layout: fixed;
width: 100%;
transform: translateY(5px);
padding-left:0px;
background-color: #4d4d4d;
margin-top:0px;
}
.tabs > li {
transition-duration: .1s;
display: table-cell;
list-style: none;
text-align: center;
/* padding: 0px 20px 25px 20px; */
position: relative;
overflow: hidden;
cursor: pointer;
color: white; 
z-index: 1;
}
.tabs > li:before {
z-index: -1;
position: absolute;
content: "";
width: 100%;
height: 120%;
top: 0;
left: 0;
background-color: rgba(255, 255, 255, 0.3);
-webkit-transform: translateY(100%);
transform: translateY(100%);
transition-duration: .1s;
border-radius: 5px 5px 0 0;
}
.tabs > li:hover:before {
-webkit-transform: translateY(70%);
transform: translateY(70%);
}
.tabs > li.active {
color:#00;
/* color: #50555a; */
}
.tabs > li.active:before {
transition-duration: .1s;
background-color: #f3f3f3;
z-index: -1;
-webkit-transform: translateY(0);
transform: translateY(0);
}

.tab__content {
/* background-color: white; */
position: relative;
width: 100%;
border-radius: 5px;
padding-left: 0px;
}
.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
.tab__content > li .content__wrapper {
/*text-align: left;*/
border-radius: 5px;
width: calc(100% - 10px);
/* padding: 45px 40px 40px 40px; */
padding-left: 10px;
/* background-color: white; */
}
> On Jun 4, 2018, at 8:22 PM, Alex Harui  wrote:
> 
> I pushed a change that should fix that.
> 
> On 6/4/18, 1:40 AM, "Harbs"  wrote:
> 
>The following CSS:
> 
>TitleBar CloseButton
>{
>   width: 16px;
>   height: 16px;
>   margin: 0px;
>}
> 
>is output as:
> 
>.TitleBar CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>Instead of:
> 
>.TitleBar .CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>I think this is a bug.
> 
>Harbs
> 
> 

Re: Incorrect descendent CSS output

[Harbs]

Thanks.

I just observed a new problem. I have not pulled in your changes, so I don’t 
know if it’s fixed, but it used to work correctly.

Much of the following css is now being stripped out.

CSS in the http://www.w3.org/1999/xhtml  
namespace should always be left in.

@namespace "http://www.w3.org/1999/xhtml;;
.printui_app .PUITabContainer .tabs {
display: table;
table-layout: fixed;
width: 100%;
transform: translateY(5px);
padding-left:0px;
background-color: #4d4d4d;
margin-top:0px;
}
.tabs > li {
transition-duration: .1s;
display: table-cell;
list-style: none;
text-align: center;
/* padding: 0px 20px 25px 20px; */
position: relative;
overflow: hidden;
cursor: pointer;
color: white; 
z-index: 1;
}
.tabs > li:before {
z-index: -1;
position: absolute;
content: "";
width: 100%;
height: 120%;
top: 0;
left: 0;
background-color: rgba(255, 255, 255, 0.3);
-webkit-transform: translateY(100%);
transform: translateY(100%);
transition-duration: .1s;
border-radius: 5px 5px 0 0;
}
.tabs > li:hover:before {
-webkit-transform: translateY(70%);
transform: translateY(70%);
}
.tabs > li.active {
color:#00;
/* color: #50555a; */
}
.tabs > li.active:before {
transition-duration: .1s;
background-color: #f3f3f3;
z-index: -1;
-webkit-transform: translateY(0);
transform: translateY(0);
}

.tab__content {
/* background-color: white; */
position: relative;
width: 100%;
border-radius: 5px;
padding-left: 0px;
}
.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
.tab__content > li .content__wrapper {
/*text-align: left;*/
border-radius: 5px;
width: calc(100% - 10px);
/* padding: 45px 40px 40px 40px; */
padding-left: 10px;
/* background-color: white; */
}
> On Jun 4, 2018, at 8:22 PM, Alex Harui  wrote:
> 
> I pushed a change that should fix that.
> 
> On 6/4/18, 1:40 AM, "Harbs"  wrote:
> 
>The following CSS:
> 
>TitleBar CloseButton
>{
>   width: 16px;
>   height: 16px;
>   margin: 0px;
>}
> 
>is output as:
> 
>.TitleBar CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>Instead of:
> 
>.TitleBar .CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>I think this is a bug.
> 
>Harbs
> 
> 

Re: Incorrect descendent CSS output

[Alex Harui]

I pushed a change that should fix that.

On 6/4/18, 1:40 AM, "Harbs"  wrote:

The following CSS:

TitleBar CloseButton
{
width: 16px;
height: 16px;
margin: 0px;
}

is output as:

.TitleBar CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

Instead of:

.TitleBar .CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

I think this is a bug.

Harbs