[aljuk]

I’m running my site in XHTML Strict, using a child theme structure. I’m having a ton of validation issues, with 91 errors generated by the activity stream alone in the BP Default Theme.

Mostly they’re due to input fields which haven’t been wrapped in block level elements and textareas without row and col attributes. Those in the theme I can fix, but some appear to be generated from core (?), and if anyone can point me at which files need attention, that would be really helpful.

There are also multiple repeated instances of id=”_wpnonce_new_activity_comment” which won’t validate under any doctype. One of these is being generated for every activity item. So my question is, how do I fix this? Is the id a target for anything, or can I strip it out? If I can’t strip it out, can I swap it for a class?

Any advice gratefully received, thanks.

[@mercime]

bp-default is running XHTML 1.0 Transitional and therein lies the big difference.

I’ve got my custom bp-default child theme (BP 1.2. passing validation, no errors. In addition, http://testbp.org, BuddyPress’ demo site using bp-default theme (BP 1.3 trunk) has only 2 errors on Activity Stream because of html5 element “role” which is not recognized in validator
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Ftestbp.org%2Factivity%2F

[Paul Wong-Gibbs]

Those roles put in to trunk are for WAI ARIA landmark.

[aljuk]

I’ve just tested on a brand new install of WP3.1 and BP1.2.8 of the box.

In Transitional, the activity stream generates 3 validation errors for every update:

`required attribute “rows” not specified`
`required attribute “cols” not specified`
`id=”_wpnonce_new_activity_comment” already defined`

this is out of the box without any mods of any sort. the lack of attributes I can fix. Also, if I run in transitional then unwrapped input fields won’t get flagged, and although I’ve always worked in strict that’s fine. But what I have no way of getting around is the mass of :

`id=”_wpnonce_new_activity_comment”`

global.js (line 330) contains :

`’_wpnonce_new_activity_comment’: jq(“input#_wpnonce_new_activity_comment”).val(),`

I’m not that great with js, but I’m wondering if the use of an id relationship could be swapped for a class relationship? If it’s just for targetting, then surely there’s no need to use an id in place of a class.

[Boone Gorges]

I think you’re probably right that this should be a class rather than an id, but it needs a bit more of an audit (in particular, a sweep through the rest of the core code to ensure that changing it to a class selector wouldn’t break everything else). @aljuk, would you mind opening a ticket on trac.buddypress.org to that effect, using the same username/pw as you do on this site?

[aljuk]

@boonebgorges not at all, thanks for response boone. I will.

I’ve just realised, through flushing cookies to check again, that these errors are thrown only for logged in users, and in a logged out state, several previous errors no longer get flagged (which is often the way when one thing is predominant in tripping up the validator). When I’m logged out, the output is entirely clean for Tranisitonal, and certainly tweakable for Strict.

[Hugo Ashmore]

I’m amazed, interest in validation

There are and have been ID errors for for ever and a day, I’ve mentioned them in the past and there’s probably a ticket lying around.
The repeated use of an Id is a common error when writing things like loops and sticking an id within one trouble is mid tier coders tend not to look at frontend output much.

Changing a DTD to get around validation errors is bad practice, new documents should always be written to a strict schema, this common use of Transitional is wrong but hey ho. What would make more sense especially given the use of attributes such as ‘roles’ (even though an XHTML spec and even though it’s actually only a working draft attribute) is a move to what is referred to as an HTML5 DTD or more accurately a DTD without a formal public identifier. TwentyTen has chosen to do this I would suggest BP can follow suite?

[aljuk]

@hnla – I second all of that. Using a Transitional DTD is about as appealing to me as switching to IE6, and repeated use of the same id in the loop is plain wrong and nasty. I’ve tried to log into trac to post there with the same credentials as I use for logging in here, but it doesn’t work.

[Hugo Ashmore]

Hmm logins should be the same here as on trac but there may be issues, we’ll put a shout out to @DJPaul @boonebgorges see if they can fix anything.

Back to validating and well formed code; of course the one bug bear in all this is the nature of plugin coding which tends to throw a huge spanner in the works, well from a theming point of view, but can be equally frustrating when you activate a plugin to find you’ll need to spend half a day hacking it to output valid code.

[aljuk]

Of course. I don’t mind hacking plugins at all – in fact I enjoy it – it’s a great way to learn, and a good way to develop conversation and feedback with other developers. But obviously it’s way harder if the basic site code is invalid since one’s then aiming at a moving target. I’m having to constantly log out to check my edits, and since my install is going to be hidden from non logged-in visitors, this presents a problem going forward. Valid markup should be a cornerstone imho.

Trac doesn’t accept my user login from this site. I have several bug reports that have cropped up with user testing from my early adopters, stretching back months in some cases, and no way of posting them.