AniDB talk:Page layout: Difference between revisions
Jump to navigation
Jump to search
Epoximator (talk | contribs) No edit summary |
mNo edit summary |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{TOCright}} | |||
== Content == | == Content == | ||
* 'g_section *_all' have been added to all pages. was this wanted? rename? g_content @ dev | * 'g_section *_all' have been added to all pages. was this wanted? rename? g_content @ dev | ||
Line 4: | Line 6: | ||
* should g_section be the only allowed element (first level childs) inside #layout-content (except h1)? | * should g_section be the only allowed element (first level childs) inside #layout-content (except h1)? | ||
::Pretty much. There can be multiples though, and it's not a hard rule (forms etc could usefully live outside and around sections). | ::Pretty much. There can be multiples though, and it's not a hard rule (forms etc could usefully live outside and around sections). | ||
:* general vertical margins. g_actionlist/etc. is subs of g_section? | |||
:::Vertical margins are a function of layout and should not be presented in the markup at all. | :::Vertical margins are a function of layout and should not be presented in the markup at all. | ||
:::was thinking '#layout-content .g_section+.g_section' here | ::::was thinking '#layout-content .g_section+.g_section' here | ||
:::::Sections are for sections, not all the pages are using them very well atm though as I just swapped them in for hr without much fiddling. | |||
* should g_navlist and g_numonpage be in one (parent) div? | * should g_navlist and g_numonpage be in one (parent) div? | ||
::Not just because. | ::Not just because. | ||
* should g_jumplist be inside the table div? | * should g_jumplist be inside the table div? | ||
::What is a 'table div'? They should be in the same section where appropriate. | ::What is a 'table div'? They should be in the same section where appropriate. | ||
::probably meant 'table be inside a div', which it is atm. we want to kill this table too, i guess | :::probably meant 'table be inside a div', which it is atm. we want to kill this table too, i guess | ||
=== Text visibility === | === Text visibility === | ||
Line 20: | Line 23: | ||
* v_neg (red) | * v_neg (red) | ||
::These tread on the toes of both <code><nowiki><font></nowiki></code> level decoration and <code><nowiki><em></nowiki></code> level meaning. Classes are about what something is, not how it should be presented. Marking pos/neg is a different issue from 'text', and the current solution is not ideal. | ::These tread on the toes of both <code><nowiki><font></nowiki></code> level decoration and <code><nowiki><em></nowiki></code> level meaning. Classes are about what something is, not how it should be presented. Marking pos/neg is a different issue from 'text', and the current solution is not ideal. | ||
:::the styles in () are just current values based on the old layout: | |||
::the styles in () are just current values based on the old layout: | :::<code><nowiki><font color="red">'''important text'''</font> -> <span(or li/td/whatever) class="v_high local_name">important text</span></nowiki></code> | ||
<code><nowiki><font color="red"> | :::so 'v_high' is just to mark it as important, not red bold (and you can choose to ignore it and just use local_name). i'm still not saying this is the right way, though. at least not the naming. (g_important/g_note/g_ano_ne etc.) | ||
::so 'v_high' is just to mark it as important, not red bold (and you can choose to ignore it and just use local_name). i'm still not saying this is the right way, though. at least not the naming. (g_important/g_note/g_ano_ne etc.) | ::::Exactly, _high _med and _low seem to be based around the current presentation of bits of text rather than the actual intended function. Markup needs to be presenting the idea that some block 'is a warning that dire things might happen if you click that button', not that the block 'is be really visible and stands out lots'. | ||
=== Text content === | === Text content === | ||
Line 37: | Line 40: | ||
* c_list (links, resources) | * c_list (links, resources) | ||
::The c_ prefix names were for collation purposes only - marked in table headers. There seems no reason for filling the namespace just because. | ::The c_ prefix names were for collation purposes only - marked in table headers. There seems no reason for filling the namespace just because. | ||
::this was for alignment in tables, yes. | :::this was for alignment in tables, yes. | ||
::::Alignment is a layout concern, and has nothing to do with collation. | |||
=== Text alignment === | === Text alignment === | ||
Line 51: | 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 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 59: | 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 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 === | ||
{| align="center" border="1" | {| align="center" border="1" | ||
Line 103: | 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 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 109: | Line 117: | ||
** pause in lists, f.ex. between normal eps and special eps | ** pause in lists, f.ex. between normal eps and special eps | ||
:::This is a function of layout, not markup. No empty rows should exist for layout purposes. | :::This is a function of layout, not markup. No empty rows should exist for layout purposes. | ||
:::agreed | ::::agreed | ||
* td.fill, width/height 100% | * td.fill, width/height 100% | ||
::This is a function of layout, not markup. | ::This is a function of layout, not markup. | ||
* .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 123: | Line 131: | ||
* div.g_image | * div.g_image | ||
::Is this actually needed? | ::Is this actually needed? | ||
::taken from "new" anime page | :::taken from "new" anime page | ||
::::That's not an answer. | |||
* div.g_end (used to mark the end of content, used for clear: right, maybe not needed) | * div.g_end (used to mark the end of content, used for clear: right, maybe not needed) | ||
::::Forgot to say, this shouldn't exist. --[[User:Rar|Rar]] | |||
* .state (creq state) | * .state (creq state) | ||
::This isn't a global meaning. | ::This isn't a global meaning. | ||
* li.here (inside g_navlist, currently selected) | * li.here (inside g_navlist, currently selected) | ||
::This isn't a global meaning. | ::This isn't a global meaning. --[[User:Rar|Rar]] | ||
== Stuff == | == Stuff == | ||
Line 135: | Line 145: | ||
* creq | * creq | ||
* message | * message | ||
::These don't seem globally relevant. | |||
=== File states === | |||
* fs_ok | * fs_ok | ||
* fs_invalid | * fs_invalid | ||
Line 141: | Line 152: | ||
* fs_generic | * fs_generic | ||
* fs_lame | * fs_lame | ||
::These | ::These are not global meanings, and the naming scheme is confusing. | ||
=== Section names (pre) === | === Section names (pre) === | ||
follows page names mostly (?show=x) | follows page names mostly (?show=x) | ||
: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. | |||
== Page types== | == Page types== | ||
Line 156: | Line 169: | ||
=== Listing === | === Listing === | ||
anime/group/producer/user | anime/group/producer/user | ||
<nowiki> [g_filterlist] (simple - separated) | |||
[g_filterlist] (simple - separated) | <g_jumplist> | ||
<g_jumplist> | <g_section (name)_list> | ||
<g_section (name)_list> | <g_jumplist> | ||
<g_jumplist> | <g_actionlist></nowiki> | ||
<g_actionlist> | |||
</nowiki | |||
=== Sub listing === | === Sub listing === | ||
latest/myvotes/myreviews/mydb (has g_jumplist too)/up2date | latest/myvotes/myreviews/mydb (has g_jumplist too)/up2date | ||
<nowiki> <g_navlist> | |||
<g_navlist> | [g_numonpage] | ||
[g_numonpage] | [g_section (name)_list] | ||
[g_section (name)_list] | [g_info] | ||
[g_info] | [g_filterlist] (ul) | ||
[g_filterlist] (ul) | [g_actionlist]</nowiki> | ||
[g_actionlist] | |||
</nowiki | |||
=== Info === | === Info === | ||
Line 179: | Line 188: | ||
*no g_sections here atm | *no g_sections here atm | ||
<nowiki> <"infobox"> (table(image,table) or div(div(div,div),p) atm) | |||
<"infobox"> (table(image,table) or div(div(div,div),p) atm) | ["votebox"] | ||
["votebox"] | [g_section list] | ||
[g_section list] | [g_info] | ||
[g_info] | <g_actionlist></nowiki> | ||
<g_actionlist> | |||
</nowiki | |||
=== Add === | === Add === |
Latest revision as of 13:03, 14 May 2009
Content
- 'g_section *_all' have been added to all pages. was this wanted? rename? g_content @ dev
- No, it's only wanted for pages with no internal sections (which is quite a few). Stuff like the calendar quite correctly has a g_section div per logical section (top and bottom nav and each anime listed).
- should g_section be the only allowed element (first level childs) inside #layout-content (except h1)?
- Pretty much. There can be multiples though, and it's not a hard rule (forms etc could usefully live outside and around sections).
- general vertical margins. g_actionlist/etc. is subs of g_section?
- Vertical margins are a function of layout and should not be presented in the markup at all.
- was thinking '#layout-content .g_section+.g_section' here
- Sections are for sections, not all the pages are using them very well atm though as I just swapped them in for hr without much fiddling.
- was thinking '#layout-content .g_section+.g_section' here
- Vertical margins are a function of layout and should not be presented in the markup at all.
- should g_navlist and g_numonpage be in one (parent) div?
- Not just because.
- should g_jumplist be inside the table div?
- What is a 'table div'? They should be in the same section where appropriate.
- probably meant 'table be inside a div', which it is atm. we want to kill this table too, i guess
- What is a 'table div'? They should be in the same section where appropriate.
Text visibility
- v_high (red bold)
- v_med (bold)
- v_low (italics)
- v_pos (green)
- v_neg (red)
- These tread on the toes of both
<font>
level decoration and<em>
level meaning. Classes are about what something is, not how it should be presented. Marking pos/neg is a different issue from 'text', and the current solution is not ideal.- the styles in () are just current values based on the old layout:
<font color="red">'''important text'''</font> -> <span(or li/td/whatever) class="v_high local_name">important text</span>
- so 'v_high' is just to mark it as important, not red bold (and you can choose to ignore it and just use local_name). i'm still not saying this is the right way, though. at least not the naming. (g_important/g_note/g_ano_ne etc.)
- Exactly, _high _med and _low seem to be based around the current presentation of bits of text rather than the actual intended function. Markup needs to be presenting the idea that some block 'is a warning that dire things might happen if you click that button', not that the block 'is be really visible and stands out lots'.
- These tread on the toes of both
Text content
- c_title
- c_text
- c_number
- c_time
- c_state (creq, message, animegroup, etc.)
- c_stats (x/x/x/x, mylist/file stats, etc.)
- c_rating (x.xx (x), mixed)
- c_action (links, report/del/rate)
- c_icons (mylist state)
- c_list (links, resources)
- The c_ prefix names were for collation purposes only - marked in table headers. There seems no reason for filling the namespace just because.
- this was for alignment in tables, yes.
- Alignment is a layout concern, and has nothing to do with collation.
- this was for alignment in tables, yes.
- The c_ prefix names were for collation purposes only - marked in table headers. There seems no reason for filling the namespace just because.
Text alignment
Default alignment. (vs. text content or in addition)
- a_center
- a_left
- a_right
- ...
or (pos)
- p_c (center)
- p_w (west)
- p_ne (northeast)
- ...
- Alignment and text positioning are functions of layout, not markup. Using anything like this is just as stupid as doing
<span class="bold">hi mum</span>
etc.- 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 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.
- 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)
- Alignment and text positioning are functions of layout, not markup. Using anything like this is just as stupid as doing
Table types
Probably don't want this /to be renamed to t_* ?
- inner (file table inside ep table, ...)
- dummy (table in title td in ep table, ...)
- 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.
- 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 MyList) - but don't need any of these classes. Any
table.inner
is just a bad way of sayingtable table
- and any handle on these will generally want to be given in a context specific way:#layout-content div.anime_table table.episodes table.files
and such.
- 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
- 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 ()
- Don't want is right. All these kinds of tables just want eradicating.
Elements
name | type | description | note | example |
---|---|---|---|---|
g_navlist | li | subpages | latest files/anime/... | |
g_numonpage (g_numofrows) | li | number of rows wanted | sub of g_navlist | |
g_jumplist (g_scrollbar) | table | ext/prev page, filter char | a navigation (prev/next) filter list | for all sortable lists |
g_actionlist (g_linklist) | - separated, to be ul? | list of different possible actions (links) | should be in most pages | |
g_definitionlist | table | vertical field name -> value list | div.anime_info div.data | |
g_infobox | non-existing | image, defintion list, description | all info pages (anime/group/ep/..) | |
g_newsbox/g_msgitem | non-existing | header(title-by-date-action) and body | news item, agcmt | |
g_navprev/g_navnext | ? | |||
g_menu | ul | page/sub menu | mylist, my messages, etc. | |
g_filterlist | ul | filtering | latest files | |
g_description | * | actual description data from db | in info boxes | |
g_info | * | used for both stats (x votes, avg. y) and general info (help/explanations) | myvotes, myreviews, mydb, etc. | |
g_howto | * | how to | agcmts |
- These need cleaning up.
Messages
- g_infobox
- g_notebox
- g_warnbox
- g_errorbox
- g_successbox
Could use g_box m_info / g_msg v_high / ...? unless g_*box is possible
- Error handling needs redoing, no point fiddling till 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 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.
- then I'll redo it, just tell me how. and markup can still be defined
- Error handling needs redoing, no point fiddling till then.
Other
- td/tr/li.pause
- pause in lists, f.ex. between normal eps and special eps
- This is a function of layout, not markup. No empty rows should exist for layout purposes.
- agreed
- This is a function of layout, not markup. No empty rows should exist for layout purposes.
- td.fill, width/height 100%
- This is a function of layout, not markup.
- .g_even, .g_odd
- With IE7, I think _even is now redundant.
- _even is part of the code logic ATM. (that's why)
- With IE7, I think _even is now redundant.
- .field, .value (in definition lists)
- These seem redundant.
- .nowrap
- This is a function of layout, not markup.
- tr.mod (mod message)
- This isn't a global meaning.
- div.g_image
- Is this actually needed?
- taken from "new" anime page
- That's not an answer.
- taken from "new" anime page
- Is this actually needed?
- div.g_end (used to mark the end of content, used for clear: right, maybe not needed)
- Forgot to say, this shouldn't exist. --Rar
- .state (creq state)
- This isn't a global meaning.
- li.here (inside g_navlist, currently selected)
- This isn't a global meaning. --Rar
Stuff
State/status/type
- file (db entries in general)
- creq
- message
- These don't seem globally relevant.
File states
- fs_ok
- fs_invalid
- fs_deprecated
- fs_generic
- fs_lame
- These are not global meanings, and the naming scheme is confusing.
Section names (pre)
follows page names mostly (?show=x)
- Yup, section prefixes should reflect page (and code generation) group.
Field names
follows DB definition mostly
- Should follow headings, not any internal db naming scheme for fields and crap.
Page types
- [] -> optional
- atm all g_ here are also g_sections @ dev
- g_jumplist is bound to listing type (scroll vs. static)
- g_*box can be on top (errors/messages), after g_jumplist (no results, only one jumplist) and on bottom (note/info/warning)
Listing
anime/group/producer/user
[g_filterlist] (simple - separated) <g_jumplist> <g_section (name)_list> <g_jumplist> <g_actionlist>
Sub listing
latest/myvotes/myreviews/mydb (has g_jumplist too)/up2date
<g_navlist> [g_numonpage] [g_section (name)_list] [g_info] [g_filterlist] (ul) [g_actionlist]
Info
anime/episode/file/group/producer
- no g_sections here atm
<"infobox"> (table(image,table) or div(div(div,div),p) atm) ["votebox"] [g_section list] [g_info] <g_actionlist>
Add
just a g_definitionlist (+ sub pages)
Simple (top-bottom)
search/news/my */ed2kdump
Special
- my list
- my place
- anime calendar
- creq pages