cubicweb #343660 [html] Replace table by divs [deprecated]

Comments

• 2009/06/16 13:06, written by fcayre-old

  I would just add the html code is one of the first thing people want to change: we should keep that in mind and always write html in (easily overridable) methods.
  • 2009/06/16 16:06, written by nchauvat

    this is true. the documentation should include a tutorial that walks the reader through the changes necessary to make his web app look like he wants (change logo, change colors, change header).
• 2009/06/16 13:37, written by acampeas

  says who ?

  we can't do complicated layouts with css, especially when building pages dynamically (cf. the long-standing bugs with related/incontext boxes that could be sanely solved only with the help of tables)

  i'd reject
  • 2009/06/16 13:38, written by acampeas

    that would be call/cell_call (as is currently, no ?)

    are there people doing otherwise out there ? how do they proceed ?
  • 2009/06/16 14:24, written by anon

    In the opposite, I would say we can't do complicated layouts with tables. They can not be styled at all, and should only be used when the semantic is correct (more, they must be used in that case). When we encounter problems styling pages, we should ask css specialists: we are not.

    Regarding the second point, when you seriously customize a cubicweb app, you can not reuse a single line of any cube if you can not easily override the html code they provide (overriding the whole call method of a view to change the html code is really stupid when the logic is complex). I really think this is the most serious limitation to code reuse in cubicweb (the other being the js lib), the other mecanisms being really great (schema reuse, appobjects, etc.).

    The usual way people handle this problem is using template engines, but as you know (discussed hundred times at Logilab), they just reinvent the wheel by providing languages to perfom loops, conditional behaviours, etc., that python does much better. However, the real-life problem of html web designer persists.

    We should be innovative regarding this point, I have some ideas (experienced from projects with outsourced design) but a serious discussion is needed. I would certainly not reject this ticket, considering it is a (small) step in the right direction.
    • 2009/06/16 15:06, written by acampeas

      on div vs tables :

      afaik there is a longstanding flamefest in the blogosphere on the topic of tables/div+css for layout and after having read both sides, I think that :

      • layout can be done, to a limited extent, with css (and browser bw compat makes this even more perilous than it is already), provided you are a css expert (which I'm not and don't want to be) and you design static web pages
      • any layout can be done with tables while keeping the code predictable (I'am asking to be proven wrong there)

      then you say "They [tables] can not be styled at all" : how is that ?

      then : "should only be used when the semantic is correct" : what does that mean ?
      • 2009/06/16 15:56, written by fcayre-old

        Perhaps my css knowledge is too bad, but I don't know how you could for example put two table rows side-by-side (or one on top of the other, or...).

        Regarding semantic: a table is something that should contain tabular data (related to each other because they belong to the same row or column), not unrelated data grouped together in a table just because it looks better.

        I completely agree with you when you say you need to be a css expert to style html markup in general. This is also why we sometimes need to change the html code, see previous topic ;-)
        • 2009/06/16 16:03, written by nchauvat

          experience proved to me that no designer will do correct html integration. html integration is always done by developers because they understand the code and html is code. designers work with the mouse and graphics, developers can use a keyboard and text. trying to make tools that will allow designers to produce directly the html code is a lost battle. if that's what you want, train your designers to become web developers, but don't make the work of developers harder than it already is and let them use a real programming language to output text (for html is only text).
          • 2009/06/16 16:07, written by anon

            I wholeheartedly agree :)

            (not ... on the "html is only text" part, but that is minor)
          • 2009/06/16 20:26, written by anon

            Total misunderstanding here it seems: I never thought (nor wrote, did I?) html designers should do html integration. We need tools to work together efficiently to build web sites.

            For me, this is essentially a project management problem: we can not wait the "end" (if this has a meaning at all in iterative development context) of the html design to integrate it. Being agile implies we are able to continously integrate html designers work. And py-templates (which is not a templating engine, nor a perfect tool -I would not use it in my projects) is a tool that could ease this task: designers only write a html sample which is programmatically transformed through pure python code (by the developer of course).

            I really do not have a solution to propose, I just come with a need: integrate html designs and re-designs faster (ultimately with no work at all).

            This task is clearly made harder by the fact that with cw (and this is one reason we really like it), pages are built by assembling very small html code parts alltogether, generated by the same number of views. An idea would be to make it easy to identify existing views in a designed page (or develop the missing views), attach them the corresponding html and develop the python code to put the real data in it. In case of a redesign, each of theses steps would stay as is or change, but not all the integration work (which usually consists in realizing these steps with no specific tool).
    • 2009/06/16 15:15, written by acampeas

      regarding code reuse wrt views:

      the question of templates is irrelevant; we don't use them because (in theory) Python is by itself a nice templating language (in practice I've done it only in private cubes were python 2.5/with statement was allowed)

      html/template reuse should follow the same guidelines as reuse in classic OO projects; the "template method" pattern can help if we are to customize parts of a view, if 'logic is complex' (but if so, then I'm asking: is your design right ? aren't you just lumping into one view what actually belongs to many, all tied by selectors (where dispatch logic should go at least) ? is performance preventing that ?)

      probably I don't see all the experience that's behind your comments, so please be patient :)

      then, I'm always working on simple problems, so I'm eager to have that serious discussion
      • 2009/06/16 15:50, written by fcayre-old

        I think the question of templates is not irrelevant: html designers just do not know python at all (and they have the right not to, although they miss something ;-)), and there is a need to work with html/ css specialists, so we need tools to build web sites together.

        The problem with template engines is that they almost always include what we called "logic", so they re-invent a programming language. I really prefer an approach like http://py-templates.sourceforge.net/ that aims at completely separating markup and logic (although not perfectly true).

        This is were the templating engine question meets the central issue you point, the one concerning complex logic. If such a complex logic exists in a view it is difficult to split markup and logic (py-templates is helpful for that I think). The question is : is that complex logic a bad design consequence? I do not know, but it is probable. The best example I experienced some time ago is with the comment cube, more precisely: CommentTreeItemView.

        Please have a look at this and let's imagine together what a better design could be, that would allow to completely redesign the way comments look like in a html page. I have to make my mind on the topic, and need you to share and spend some time thinking about that.
        • 2009/06/16 16:16, written by acampeas

          First, if html designers have a right to ignore python programmers, then I ask the right to ignore them, and not depend on them ... (ui design may be a specific skill, but not up to the point where you don't need to be at least a programmer to practice it)

          Think about qt/gtk : do we need to know these toolkits to practice ? sure ?! do we depend on so-called über specialist to make gui layouts that work ? I believe not.

          I'l have a look at the comment cube (which seems broken by the way, as I can see writing these comments that don't attach themselves where they ought to).

          Then, last point: where does come this notion/requirement that it is desirable to allow to "completely redesign the way XXX look" in a html page ? What is the extent of such a demand ? That the same "comment thread" view may be given a radically different layout by virtue of css magic ?

          Do we ask such things when it comes to fat clients gui ?
          • 2009/06/16 21:00, written by fcayre-old

            My point is all about working efficiently together with web designers. I think web design is a skill you do not need to be a good programmer to be good at.

            About specialists : making web layout that work is just easy. A web layout must not only work, but look the way the creative people want it to look like. If you can make web layouts that work and respect the work of creative people yourself, it is great (please consider working for SecondWeb ;-)), but even so it is not real life, where you need several people working together as fast as possible to produce high quality code (python, html, css, javascript for instance). We then want the best people, and among them, the best html/ css designers. I am not among those who can pretend being good "backoffice" and a good html designer, so I asserted not being alone in that case, thus the need for working more efficiently with skilled html/ css designers.

            Regarding the "complete redesign" requirement, it comes from our clients (very different from yours, I agree), who really want nice looking pages (this is all about marketing). The problem is css is not enough to achieve this, and we need to develop customized views; very often the customized views do not do much but slightly change the initial html, which should be made easier if we want to be faster.

            Regarding fat clients gui: I do not know, but I don't care, they do not address my needs for web applications. CubicWeb does, and I think it is the best tool for what I want to do, that's why I try to explicit my needs and the reason for them so that we adapt the tool or the way we work with it.
• 2009/06/17 13:17, written by ksaurfelt

  I totally agree with fcayre saying that we need to rethink our html/css strategy - the main layout as well as cubes views.
• 2010/01/16 13:59, written by acampeas

  http://www.flownet.com/ron/css-rant.html (Why CSS should not be used for layout)

  This one sums up things neatly.
  • 2010/01/16 14:03, written by acampeas

    http://www.newmediacampaigns.com/page/why-css-should-be-used-for-layout tries to answer, but agrees that the following points:

    * You're not creating a document, you're creating an application. CSS was designed for documents.
    * There are few, if any, semantic or accessibility reasons to do layout with CSS when the page is being built by Javascript.
    * You have a proper server-side HTML templates layer
    

    ... play against css for layouts.