Table Alignment
One of the great challenges of writing an HTML editor is discovering and smoothing over all the weird complexities in HTML. There are just some areas of HTML (and CSS) that are brain-dead stupid and you have to wonder how on earth it ever came to be like that. I suspect most of those brain-dead areas are involved with alignment or tables. This of course means that aligning tables is particularly stupid.
Let’s start with just HTML. There’s an align attribute in HTML which seems nice and straight forward <p align=”right”> will align the the paragraph content to the right. <p align=”center”> will center the paragraph content. Unfortunately this doesn’t hold true for tables. <table align=”left”> will float the table itself left, allowing the text to wrap around the table. <table align=”right”> will do the same on the right, but <table align=”center”> will just center the table itself, without wrapping text around it.
Now add in CSS – which at least by itself is much more sensible. <table style=”text-align: center”> has no effect on the table itself, but centers all the contents of the cells. <table style=”float: left”> floats left as does float: right. So far so good, but what if we want to center the table itself? That would be <table style=”margin-left: auto; margin-right: auto;”> What the?
I’m sure there are good and logical reasons for all these crazy things, but anyone who’s tried to provide an align attribute in a table dialog that’s compliant with both old and new browsers and is intuitive for users has quite significant bald patches because of this.
March 11th, 2009 at 7:35 pm
What (old) browsers that doesn’t support ‘margin: 0 auto’ is it you want or need to support? Even Internet Explorer 6 (in non-quirks mode) supports this. Do you, for some inexplicable reason, need to support Netscape 4 or older versions of IE?
While I can agree that ‘margin: 0 auto’ isn’t the most intuitive way to center a block-level element (there should bee a ‘float: center’), ‘text-align: center’ very intuitively works just the way you expect and will of that reason not center anything other than (inline) text. Block-level elements need block-level adjustment properties, and that’s where ‘float: left | right’ and ‘margin: 0 auto’ comes in.
So, the conclusion is that if you don’t need to support less than 0.1% market share and dark age-ancient browsers, there’s exactly three different CSS property/value pairs you need to set for three different visual alignments for a given block; ‘align: left’, ‘align: right’ and ‘margin: 0 auto’. Not too hard, is it? :-)
PS: I’ve probably asked for this before, but here I go again: Comment preview would be very nice. :-)
March 11th, 2009 at 7:38 pm
(Forget this comment; I just want to be notified of followup comments via e-mail :-)
March 13th, 2009 at 5:43 am
Except that when you deal with real world HTML you can’t just limit things to CSS float and margin-left: auto; margin-right: auto (margin: 0 auto is actually quite different to those two rules as I’m sure you’re aware). You’re going to encounter HTML that still uses the align attribute. Plus a lot of PDF convertors and most XSLT transformations don’t handle CSS well, if at all. If you live in a world where all you care about is the commonly used browsers, life is much easier – sadly, there are just enough other types of HTML parsers and just plain lousy HTML out there to cause lots of problems.
March 13th, 2009 at 5:44 am
Oh and yes, comment preview would be nice. So would openid support…. Just need a few round tuits.
March 19th, 2009 at 8:11 am
My understanding was that you produced HTML, not consumed. I see now that my understand was incorrect, so much of my comment is thus void. Wrt the difference between ‘margin: 0 auto’ and ‘margin-left: auto; margin-right: auto’ — it was only an example and a shortcut. :-)
March 19th, 2009 at 10:03 am
It’s true editors only produce HTML, but our customers have to consume it. It’s a bit naive to think that someone could produce HTML and then not have to deal with the consequences of people trying to consume it.
And believe me, people consume HTML with some pretty strange combinations of software :)
March 19th, 2009 at 6:13 pm
If you want your customers to be able to consume the HTML in something different from a regular web browser; yea, indeed.
March 19th, 2009 at 6:49 pm
While the uses for HTMl we generate is varied and does quite often cause issues, the bigger problem is actually the incoming HTML that we have to consume. A HTML editor doesn’t always start from a blank document and shouldn’t be limited to just the HTML it authored. So we not only have to parse and display arbitrary HTML like browsers do, we have to make it fit into a sensible form within dialogs etc so the user can actually work with it and then somehow produce valid output at the end. Plus any corrections for validity need to render exactly the same in browsers.
In other words, we poor editor guys get all the problems the browser guys do, plus all the challenges of the generator guys and few problems specific to editors. Remind me why I work here again? :)
March 19th, 2009 at 11:38 pm
I see your point entirely, but having to deal with odd markup should preferably be up to some kind of filter in front of the editor, so all the oddities are washed away and replaced with valid techniques so that the editor doesn’t need to handle all the craziness your customers are generating. That would at least be my take on it.
March 20th, 2009 at 3:19 am
We do in fact have a filter in front of the editor, but as always there’s problems there too. If the filter aggressively normalizes content into a particular form, clients who want the original form for whatever reason will complain. So you need to preserve the non-normalized form through to the editor and only change things if the author actually changes the values – that means the editor has to deal with all the different variants though. So while the filter can at least guarantee that the content is well-formed and compliant, it still doesn’t solve completely normalize the HTML.
Even with the filtering levels we have now, which are reasonably tame, we’re getting a number of requests for the editor to just leave the HTML as-is. There are unfortunately, no silver bullets to this type of problem – just a whole lot of corner cases.
March 21st, 2009 at 9:43 pm
Asbjørn,
You’ll be pleased to know the site now has comment preview. I’m not 100% happy with the layout of it but it will do for now.
I also added openid authentication to verify your comment and skip the moderation queue.
March 21st, 2009 at 11:00 pm
Ah, excellent. I think it works more than well enough. :)