1,633
edits
AniDB talk:Page layout: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 55: | Line 55: | ||
* ... | * ... | ||
::Alignment and text positioning are functions of layout, not markup. Using anything like this is just as stupid as doing <code><nowiki><span class="bold">hi mum</span></nowiki></code> etc. | ::Alignment and text positioning are functions of layout, not markup. Using anything like this is just as stupid as doing <code><nowiki><span class="bold">hi mum</span></nowiki></code> etc. | ||
:::almost, the idea was 'easy/default | :::almost, the idea was 'easy/default behaviour' so you don't have to specify every bit and piece in css. but it's based on failed laziness, i guess. (is using align and valign better? i wouldn't think so) | ||
::::Actually, align="" etc *is* better, as then at least you're using well defined HTML layout syntax for layout purposes, rather than inventing your own terms and hiding everything behind a needless layer of indirection. Thinking pulling shit like this is doing a | ::::Actually, align="" etc. *is* better, as then at least you're using well defined HTML layout syntax for layout purposes, rather than inventing your own terms and hiding everything behind a needless layer of indirection. Thinking pulling shit like this is doing a CSS rewrite is as dumb as replacing every tag with a div with the tagname in the class and using CSS like div.span { display: inline; } etc. | ||
=== Table types === | === Table types === | ||
| Line 64: | Line 64: | ||
* container (not inner, for layout only, f.ex. vote section @ anime page) | * container (not inner, for layout only, f.ex. vote section @ anime page) | ||
::Don't want is right. All these kinds of tables just want eradicating. | ::Don't want is right. All these kinds of tables just want eradicating. | ||
:::like | :::like I thought. it's not that easy to eradicate, though. at least when you don't know any good css solutions for them. show me how and I'll do it, see () | ||
::::I made an anime page mockup like a year ago with no layout tables. Wasn't quite clear though - nothing wrong with table inside table in the rare cases it's actually wanted (anime page and | ::::I made an anime page mockup like a year ago with no layout tables. Wasn't quite clear though - nothing wrong with table inside table in the rare cases it's actually wanted (anime page and MyList) - but don't need any of these classes. Any <code>table.inner</code> is just a bad way of saying <code>table table</code> - and any handle on these will generally want to be given in a context specific way: <code>#layout-content div.anime_table table.episodes table.files</code> and such. | ||
=== Elements === | === Elements === | ||
| Line 110: | Line 110: | ||
unless g_*box is possible | unless g_*box is possible | ||
::Error handling needs redoing, no point fiddling till then. | ::Error handling needs redoing, no point fiddling till then. | ||
:::then | :::then I'll redo it, just tell me how. and markup can still be defined | ||
::::Currently exp returns either (number, message) pairs or just numbers from the | ::::Currently exp returns either (number, message) pairs or just numbers from the DB backend, and then the front end sometimes looks at the number, sometimes generates its own errors, and variously tries to print them in some kind of output page which varies from script to script. It's a total mess, but not one that is in need of urgent fixing. Leave it alone - really not anything monkey patching is going to make better. If AniDB ever moves over to error handling that actually has some plan and direction, can fiddle with the output then. | ||
=== Other === | === Other === | ||
| Line 122: | Line 122: | ||
* .g_even, .g_odd | * .g_even, .g_odd | ||
::With IE7, I think _even is now redundant. | ::With IE7, I think _even is now redundant. | ||
:::_even is part of the code logic | :::_even is part of the code logic ATM. (that's why) | ||
* .field, .value (in definition lists) | * .field, .value (in definition lists) | ||
::These seem redundant. | ::These seem redundant. | ||
| Line 157: | Line 157: | ||
:Yup, section prefixes should reflect page (and code generation) group. | :Yup, section prefixes should reflect page (and code generation) group. | ||
=== Field names === | === Field names === | ||
follows | follows DB definition mostly | ||
:Should follow headings, not any internal db naming scheme for fields and crap. | :Should follow headings, not any internal db naming scheme for fields and crap. | ||