Success! Looks like we've fixed this one. According to our records the fix was applied for EXTJS-5846 in a recent build.
  1. #1
    Sencha User
    Join Date
    Nov 2008
    Location
    Lyon, France
    Posts
    223
    Vote Rating
    29
    christophe.geiser has a spectacular aura about christophe.geiser has a spectacular aura about

      0  

    Default [4.1 RC2] problem with id starting with non-word char

    [4.1 RC2] problem with id starting with non-word char


    Hi all,

    please try this :

    Code:
    win = new Ext.window.Window({title: 'not working', id: '<123/>'});win.show()
    and then drag the window.

    The error raised (Uncaught Ext.Error: Error parsing selector. Parsing failed at "#<123/>_header") is probably due to the fact that the token for testing select path is maybe a bit restrictive.

    in Ext.DomQuery.compile, we have:
    Code:
    while(path && lastPath != path){                lastPath = path;
                    tokenMatch = path.match(tagTokenRe);
                    if(type == "select"){
                        if(tokenMatch){
    
                            if(tokenMatch[1] == "#"){
                                fn[fn.length] = 'n = quickId(n, mode, root, "'+tokenMatch[2]+'");';
                            }else{
                                fn[fn.length] = 'n = getNodes(n, mode, "'+tokenMatch[2]+'");';
                            }
                            path = path.replace(tokenMatch[0], "");
                        }else if(path.substr(0, 1) != '@'){
                            fn[fn.length] = 'n = getNodes(n, mode, "*");';
                        }
    
                    }else{
                        if(tokenMatch){
                            if(tokenMatch[1] == "#"){
                                fn[fn.length] = 'n = byId(n, "'+tokenMatch[2]+'");';
                            }else{
                                fn[fn.length] = 'n = byTag(n, "'+tokenMatch[2]+'");';
                            }
                            path = path.replace(tokenMatch[0], "");
                        }
                    }
    with tagTokenRe defined as /^(#)?([\w\-\*\\]+)/ and path as '<123/>', tokenMatch will always be null for ids starting with a non-word char, and thus the DomQuery will not search matching token by ids.
    Cheers,
    C.

  2. #2
    Ext JS Premium Member danattfield's Avatar
    Join Date
    Sep 2011
    Location
    London, UK
    Posts
    21
    Vote Rating
    0
    danattfield is on a distinguished road

      0  

    Default


    We've found that having a number at the start of the ID causes a massive error - DOM Exception 12. Sure, having numbers at the start of ID attributes is illegal - but at least 3.x and 4.0.x (and even 4.1 RC1) previously didn't explode.

    We've reverted back to RC1 for the time being which seemed to be getting there. There are too many strange behaviours and seemingly fundamental changes in RC2 causing bugs that we don't have time right now to look into.

  3. #3
    Sencha - Support Team scottmartin's Avatar
    Join Date
    Jul 2010
    Location
    Houston, Tx
    Posts
    9,154
    Vote Rating
    475
    scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future scottmartin has a brilliant future

      0  

    Default


    This is not supported. The fact that RC1 did not enforce the HTML5 rule should not be a cause to stop using.
    Several items that were allowed in 4.07 are not enforced in 4.1. To be compliant, rules have to be enforced.

    Regards,
    Scott.

  4. #4
    Sencha User
    Join Date
    Nov 2008
    Location
    Lyon, France
    Posts
    223
    Vote Rating
    29
    christophe.geiser has a spectacular aura about christophe.geiser has a spectacular aura about

      0  

    Default


    Thanks for your replies

    From W3C HTML5 specs:
    Code:
    3.2.3.1 The id attributeThe id attribute specifies its element's unique identifier (ID). The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.
    An element's unique identifier can be used for a variety of purposes, most notably as a way to link to specific parts of a document using fragment identifiers, as a way to target an element when scripting, and as a way to style a specific element from CSS.
    If the value is not the empty string, user agents must associate the element with the given value (exactly, including any space characters) for the purposes of ID matching within the element's home subtree (e.g. for selectors in CSS or for the getElementById() method in the DOM).
    Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute.
    This specification doesn't preclude an element having multiple IDs, if other mechanisms (e.g. DOM Core methods) can set an element's ID in a way that doesn't conflict with the id attribute.
    
    The id IDL attribute must reflect the id content attribute.
    imho, the rule being enforced in this specific case (basically ids should be an xml token) is not an HTML 5 rule (or at least I could not figure out where this rule is specified) . Can your review this and eventually file it as a bug ?

    Cheers,
    C.

  5. #5
    Sencha User
    Join Date
    Nov 2008
    Location
    Lyon, France
    Posts
    223
    Vote Rating
    29
    christophe.geiser has a spectacular aura about christophe.geiser has a spectacular aura about

      0  

    Default


    Right. Looking a bit further into this, HTML4 specifies:
    Code:
    ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
    But I don't see any reason for enforcing an HTML4 rule here.

    rapid dirty workaround for this (in Ext.panel.Panel.updateHeader) :
    Code:
     header = me.header = Ext.widget(Ext.apply({
                        xtype       : 'header',
                        title       : title,
                        titleAlign  : me.titleAlign,
                        orientation : vertical ? 'vertical' : 'horizontal',
                        dock        : me.headerPosition || 'top',
                        textCls     : me.headerTextCls,
                        iconCls     : me.iconCls,
                        icon        : me.icon,
                        baseCls     : me.baseCls + '-header',
                        tools       : tools,
                        ui          : me.ui,
                      //  id          : me.id + '_header', // DIRTY: comment this line for preventing parsing errors on ids
                        indicateDrag: me.draggable,
                        frame       : me.frame && me.frameHeader,
                        ignoreParentFrame : me.frame || me.overlapHeader,
                        ignoreBorderManagement: me.frame || me.ignoreHeaderBorderManagement,
                        listeners   : me.collapsible && me.titleCollapse ? {
                            click: me.toggleCollapse,
                            scope: me
                        } : null
                    }, me.header));
                    me.addDocked(header, 0);

    C.

Thread Participants: 2