[00:01] Project windmill-devel build #149: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/149/ [00:05] sinzui: [00:06] sinzui: is there a reason why css_id doesn't like '_' [00:06] ie it replaces '_' with '-' [00:17] wallyworld: css2 back -ages- ago forbade underscores [00:17] wallyworld: since permitted, but EOldBrowsers [00:19] Can someone take a look at bug #787650.. It appears to be in lp:launchpad already.. Should it be either fix comitted or fix released? [00:19] <_mup_> Bug #787650: Add an IRC nick formatter < https://launchpad.net/bugs/787650 > [00:20] or am I missing something [00:20] cjohnston: fix committed happens when it gets through CI [00:20] so in lp:launchpad/stable [00:20] 'ok [00:20] aka lp:~launchpad-pqm/launchpad/stable [00:21] lifeless: hmm. even though css_id() strips them, most all of our form fields still have them [00:21] fix released happens when its live and the bug corrected [00:21] ie css_id is not used iniversally [00:21] this may explain some old browser issue - but it would need to be really old browsers :) [00:22] lifeless: so since fields like target_branch etc are rendered in the current codebase, do we want to retain the behaviour of css_id() to strip the _ [00:23] wallyworld: I'm not enough of a browser-changelog-guru to know [00:23] np. i'm asking because it would allow me to eliminate some duplicate code [00:24] I suggest some research - find which version of IE started supporting them, for instance [00:25] i'll have a look. but given we render nodes with ids containing _ right now, it's kinda moot, no? [00:25] well [00:25] we know we have ie6 issues [00:25] this might be it, for instance. [00:26] given we know we have some browser issues, its probably a good idea to exclude this change from those issues before making it ;) [00:26] could be. i doubt we're going to address any ie6 compatability issue though? [00:27] we would like to [00:27] * wallyworld hates ie6 :-( [00:27] yes [00:28] http://noscope.com/journal/2005/01/showing-css-to-ie-only-the-underscore-hack [00:32] ah, thats different [00:39] http://www.w3.org/TR/CSS21/syndata.html#characters is what permits _. http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html#q4 is the older spec. [00:41] 6.0 was release in 2001 [00:43] http://www.w3.org/TR/2002/WD-CSS21-20020802/ is the earliest 2.1 draft I've found so far [00:43] lifeless: from what i can tell, ns4 has an issue with _. ie6 is ok [00:44] although with ie6, _ as the first character has special meaning [00:44] yeah [00:44] wth they thought that was a good idea, we'll never know [00:44] as you point out above, _ as the first char is for ie6 only properties [00:45] so i think it should be ok to allow _, but not as the first char? [00:45] probably [00:45] I suspect you'll want to run it past e.g. sinzui [00:45] yeah [00:47] it would be nice to be able to do it so that we can have a cleaner codebase and consistent id generation for popups vs other fields [01:34] Project db-devel build #588: FAILURE in 5 hr 44 min: https://lpci.wedontsleep.org/job/db-devel/588/ [04:26] Project windmill-db-devel build #335: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-db-devel/335/ [05:13] Project windmill-devel build #150: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/150/ [05:58] Project windmill-db-devel build #336: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-db-devel/336/ [06:21] poolie, lifeless: Thanks! [06:56] Yippie, build fixed! [06:56] Project db-devel build #589: FIXED in 5 hr 21 min: https://lpci.wedontsleep.org/job/db-devel/589/ [09:47] Project windmill-db-devel build #337: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/337/ [14:03] Project windmill-db-devel build #338: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/338/ [17:41] Project db-devel build #591: FAILURE in 5 hr 21 min: https://lpci.wedontsleep.org/job/db-devel/591/ [23:03] Project db-devel build #592: STILL FAILING in 5 hr 21 min: https://lpci.wedontsleep.org/job/db-devel/592/