AniDB

hikaru2895 wrote:Please return the animelist to left justification for titles, thank you.

Amour wrote:2) left-align the input boxes

Amour wrote:On the "add file" page:
1) Please left-align all the input boxes/fields, thanks.

DonGato wrote:On Add file to your anime list wouldn't be better to align the NOTE in accordance to the title?
And there is a back in some of these pages. That shouldn't be centered?

Successfully added anime page has Synonyms and Shortnames, Sequels and Prequels, and Genres links aligned to the left. They should be centered.

Klibbnisse wrote:Well, the animenames in the mylist... i liked it better before when they were aligned to the left...

Don't bug-report pages that aren't changed yet... it's just the old code was broken and the site coming out of quirks mode shows that. All that's new currently is the layout markup and the main page, we'll do the rest as we come to it, in the mean time use Firefox or Opera, several of the complaints above (hikaru2895, Amour*2, Klibbnisse) are IE only.

Rar

Ok, so we will start to see errors all over during the change.
It's better you post that to stop bug reports.

In Firefox (1.5), i can't middle click the search button to open the search in a new tab like i used to be able to.

Thats perfectly normal, because its no links anymore, but a button

ok edit: I safari i can open with middle mousebutton in new tab, but firefox can't because of a "feature" taht it searches in google with the Clipboard content whan you middleclick anywhre

Why destroying the compliance with IE?

You're supposed to improve AniDB, not to deteriorate it.

The compliance isn't destroyed, IE is jsut unsupported
since the gzip issue. ^^

Amour wrote:Why destroying the compliance with IE?

You're supposed to improve AniDB, not to deteriorate it.

It'll most likely work better in MSIE 7, a realease that is FIVE years overdue.
Until then, surf smart, surf safe, surf using another browser.

The main purpose of the change is that it should allow for new improved layouts. Unfortunately IE breaks ALL "dynamic" stuff, it's the nature of the browser. Maybe someone will make an IE version of the page, it's supported now after all. it wasn't really before.

Right, align should be pretty much emulated right in browsers that support the > selector (so, DonGato's stuff from above should work). As stuff is going to be changing, refresh if you see new odd things and esure you've got the current stylesheets.
Petri's brown style is back, inmport it from http://www.anidb.net/css/brown2/brown2.css in your profile settings - it's not behaving quite as well as the default atm, but I'm on it.
Thanks MaJutsu for the pics, 's actually quite encouraging, just need to sort out float issues on the msgs page.

The tab from search, Mr Lampshade, is I suspect the same as MaJutsu's complaint in Safari earlier (IT WAS NEVER A LINK THOUGH :), either way it's inconsistant handling of html forms, if they let you tab from a 'image' input control but not a 'submit' input control:
(old) <input name="do.search" src="http://www.anidb.net/pics/button_search.gif" height="14" type="image" width="63">
(new) <input type="submit" name="do.search" value="search" class="submit" />
As a submit is what it is, I'm reluctant to change it in markup, alternative solution probably best.

Rar

When using Camino in Mac OS X, the search button doesn't have any text. With Safari it does appear and with Firefox the text is on the lower side of the button.

You turn images off, by any chance? You'll want to use a css file that's aware of that fact. Or just use brown2 instead for the moment.

Rar

Rar wrote:Right, align should be pretty much emulated right in browsers that support the > selector (so, DonGato's stuff from above should work). As stuff is going to be changing, refresh if you see new odd things and esure you've got the current stylesheets.

Alignment is now working with IE. Thanks.

The validator whinges about the main page: the login form is missing a <p>, and the 'remember me' <label> isn't closed.

Also, the inlined news articles are Transitional, while the main page is Strict.

elfish wrote:The validator whinges about the main page: the login form is missing a <p>, and the 'remember me' <label> isn't closed.

Also, the inlined news articles are Transitional, while the main page is Strict.

The label is properly closed.

The missing <p> is not missing but a </p> is added incorrectly on the end of the section.


Don't run a validator on something if you don't understand what it says...

The <label> is indeed closed correctly; I wasn't paying attention. Apologies.

Are we, however, maybe talking about a different <p>? There's no <p> or </p> inside the login <form>. As I understand it (and the spec seems to be stating), you can't put inline elements (which <input> is) inside a <form>, only block elements. To put an <input> inside a <form>, there has to be a block element between them.

Example: <form><input/><input/><input/></form> on its own is not valid, but <form><p><input/><input/><input/></p></form> is.

Thus on the validator's output, there needs to be a <p> on line 36, after "<form action="animedb.pl" method="post">", closed on line 42 after "</form>"

Even if my analysis completely wrong, I still stand by my bug report: that you're using XHTML/Strict implies that you care about valid HTML, and would be interested to know when your HTML doesn't validate. I don't think your hostility was necessary or productive.

Validation is just a tool. People who put buttons saying 'this is valid xxx' on their sites are tards. Yes, those alerts are mostly about the DTD of xhtml having some odd decisions about what can contain what - really what xhtml *should* say is "don't use html forms", but they are trying to make a show of compatibility.
In my mind, the only relevance of doctypes at the moment while we're poking the code of the site is what triggers quirks and what doesn't. If we were serving as xml, the pages wouldn't render if they weren't well formed, but tag soup is tag soup, if basically works during switchover that'll do.

Rar