AniDB talk:Page layout: Difference between revisions

From AniDB
Jump to navigation Jump to search
(Comments)
(tonpon)
Line 6: Line 6:
** general vertical margins. g_actionlist/etc. is subs of g_section?
** 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
* 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


=== Text visibility ===
=== Text visibility ===
Line 18: Line 20:
* 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:
<code><nowiki><font color="red"><b>important text</b></font> -> <span(or li/td/whatever) class="v_high local_name">important text</span></nowiki></code>
::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.)


=== Text content ===
=== Text content ===
Line 31: Line 37:
* 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.


=== Text alignment ===
=== Text alignment ===
Line 44: Line 51:
* ...
* ...
::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 behavoir' 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)


=== Table types ===
=== Table types ===
Line 51: Line 59:
* 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 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 ()
=== Elements ===
=== Elements ===
{| align="center" border="1"
{| align="center" border="1"
Line 76: Line 84:
|-
|-
|g_filterlist||ul||filtering||||latest files
|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
|-
|-
|}
|}
Line 81: Line 95:


=== File states ===
=== File states ===
* g_fs_ok
* fs_ok
* g_fs_invalid
* fs_invalid
* g_fs_deprecated
* fs_deprecated
* g_fs_generic
* fs_generic
* g_fs_lame
* fs_lame
::These don't need to be in the global namespace.
::These don't need to be in the global namespace.


Line 97: Line 111:
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 i'll redo it, just tell me how. and markup can still be defined


=== Other ===
=== Other ===
Line 102: 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
* 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.
* .g_description
::_even is part of the code logic atm. (that's why)
* .g_info
* .g_howto
::These three probably want better and clearer definition.
* .field, .value (in definition lists)
* .field, .value (in definition lists)
::These seem redundant.
::These seem redundant.
Line 118: Line 131:
* div.g_image
* div.g_image
::Is this actually needed?
::Is this actually needed?
::taken from "new" anime page
* 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)
* .state (creq state)
* .state (creq state)
Line 123: Line 137:
* 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.
== Stuff ==
=== State/status/type ===
* file (db entries in general)
* creq
* message
=== Section names (pre) ===
follows page names mostly (?show=x)
=== Field names ===
follows db definition mostly

Revision as of 11:21, 13 December 2006

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
  • 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

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"><b>important text</b></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.)

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.

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 behavoir' 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)

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 ()

Elements

name type description note example
g_navlist li subpages latest files/anime/...
g_numonpage li number of rows wanted sub of g_navlist
g_jumplist table ext/prev page, filter char for all sortable lists
g_actionlist - separated 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.

File states

  • fs_ok
  • fs_invalid
  • fs_deprecated
  • fs_generic
  • fs_lame
These don't need to be in the global namespace.

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

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
  • 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)
  • .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
  • div.g_end (used to mark the end of content, used for clear: right, maybe not needed)
  • .state (creq state)
This isn't a global meaning.
  • li.here (inside g_navlist, currently selected)
This isn't a global meaning.

Stuff

State/status/type

  • file (db entries in general)
  • creq
  • message

Section names (pre)

follows page names mostly (?show=x)

Field names

follows db definition mostly