1

Dumb Ideas / The new phenomenon in accessible, semantic, standards-compliant markup: tables!!

« Last post by Peter Hall on Today at 05:48:51 AM »

 

I've been obsessed for a while about how forums can be marked up without either resorting to non-semantic code or the kind of horrible, messy, confusing collection of nested ULs and DLs that some boards (phpBB, among one or two others) are using these days.

I've come to the conclusion that the proper way to deal with most forum data is by using tables, because it displays tabular data.  The old-school forums that used tables for layout purposes used too many rows and not enough columns to display their data semantically.

Take topic view, for example. Post body and post options in the same column, in different cells. Poster name and contact info in the same column, sometimes in the same cell. Bleh.

I've designed a new topic view with four columns, so that uninterested users can ignore the user info and the post options if they want, leaving the most important stuff - post body and username - in columns of their own. I have, however, used a little CSS positioning to make it look more or less normal.

And here it is: http://www.peterhall.me.uk/workspace/tabular-posts/

Yes, it's missing a couple of things like an avatar, a user rank, some nice colours and images etc., but it's only a proof of concept.

I've put a little style switcher on it too, so you can see it's actually four columns. And I've attached it, in case you want to meddle with it.

It could perhaps be improved in one way: if I were to make it five columns, with the contact details in a separate one from the user stats. Because the content of the "missing" columns is absolutely positioned, it would have to go somewhere relatively predictable - for example, where the post title is now, rather than under the user stats which are of variable length. But who uses post titles anyway?

In my view it's the most accessible way the topic view has ever been laid out. Opinions please! (And don't be light on me, I'm used to getting a bashing for my efforts )

2

Dumb Ideas / Re: parse_bbc profiling

« Last post by [Unknown] on September 06, 2010, 10:49:47 AM »

It's all very abstract... What improvements could you think of?

Well, I would probably build using an array, since the concatenation is killing it.  That said, I'd want to profile it first.

Really, I would cut it into a couple functions which would probably greatly help profiling it.  Then you could actually see what's going on with large things.

I only wonder whether this can all be accelerated with regex. I'm pretty sure it can. I mean, just have a look at Footnotes... Now that's some complicated stuff. It can all be put into little functions...

Regular expressions was how it was built before this iteration.  Those had:

1. Major security problems.
2. In general (at least compared to my original) worse performance.
3. No customization options and confusing syntax.
4. Nearly undetectable/unfixable problems with lists and tables being used improperly.
5. Practically zero chance of being able to promise to output valid XHTML (which is also important for security and not breaking layout.)

The new parser was at least meant to fix these things.  And as far as I know, it did, all of them.  To me, going back to regular expressions seems like it would be a huge regression in all of these areas.

If anything, for high perf, I would have a C library that would do the bbc parsing itself (it would just need to take a nice set of extensible options.)  I doubt this would be hard, and there may be some already out there.  People who care about performance probably would not have a huge problem installing such a PHP extension.

-[Unknown]

3

Dumb Ideas / Re: parse_bbc profiling

« Last post by Nao on August 31, 2010, 11:03:35 AM »

I talked about it once recently.  There's tons of things that can be done.  I don't think people even realize how much better it is than what used to be used.  The first "phase" of parse_bbc() was just feature parity with the old version, and better security, not perf.

It's all very abstract... What improvements could you think of?

I only wonder whether this can all be accelerated with regex. I'm pretty sure it can. I mean, just have a look at Footnotes... Now that's some complicated stuff. It can all be put into little functions...

We really need to discuss this at some point!

4

Dumb Ideas / Re: parse_bbc profiling

« Last post by AngelinaBelle on August 30, 2010, 08:52:43 AM »

I imagine you'd only want this during testing.
Or when you had a problem. Like with a chatbox hanging on email adresses, or some such thing...

5

Dumb Ideas / Re: parse_bbc profiling

« Last post by [Unknown] on August 28, 2010, 09:34:39 PM »

There was a topic by... I don't remember whom... Posted... I don't remember where... That discussed potential improvements for parse_bbc() performance... Where was that already?

I talked about it once recently.  There's tons of things that can be done.  I don't think people even realize how much better it is than what used to be used.  The first "phase" of parse_bbc() was just feature parity with the old version, and better security, not perf.

-[Unknown]

6

Dumb Ideas / Re: parse_bbc profiling

« Last post by Nao on August 28, 2010, 04:18:38 PM »

There was a topic by... I don't remember whom... Posted... I don't remember where... That discussed potential improvements for parse_bbc() performance... Where was that already?

7

Project Discussion / Re: TOX-G 0.1-alpha1

« Last post by Nao on August 28, 2010, 02:31:03 AM »

Okay thanks, it's all I needed to know
(Take your time, no hurry.)

8

Dumb Ideas / Re: parse_bbc profiling

« Last post by [Unknown] on August 27, 2010, 09:49:33 PM »

Do you mean during runtime?

Such a thing would have to be enabled and disabled (or sampled perhaps?), because otherwise it would definitely eat more CPU than the actual usage itself.

If you mean using test cases, this was originally the plan.  There were test cases written, and every intention to have performance measured on them, and manage regressions through them.  Unfortunately I never explained these plans in detail (although I checked in the first few tests), so no one else ever looked at the tests or used them after I left.

In general I think running xhprof against a slow page would tell us a lot of what we need to know without having to add tons of instrumentation.

-[Unknown]

9

Project Discussion / Re: TOX-G 0.1-alpha1

« Last post by [Unknown] on August 27, 2010, 09:44:32 PM »

Off topic -- [Unknown], did you get my PM? Just want to make sure you read it

Yes, have not had a chance to consider it yet.

-[Unknown]

10

Project Development / Re: Debug Class

« Last post by [Unknown] on August 27, 2010, 09:43:34 PM »

Well, that's what I mean.  The mechanics of timing or counting, and whether it should be tracked right now or not, and whether or not the last page view should count or this one is a redirect, etc. would all be handled centrally.  That's the point.

I think we're agreeing, no?

-[Unknown]