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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 
wrote:
    >>> 
    >>> 
    >>> 
    >>> On 6/5/18, 2:29 PM, "Harbs" <[email protected]> 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
    >>> 
    >>> 
    >> 
    >> 
    >> 
    > 
    
    

Reply via email to