[Sommaire] [Imprimer]

   1  Old browsers and Kupu
   2  =====================
   3  
   4    Written by: Guido Wesdorp
   5    Email: guido@infrae.com
   6    Valid for: Kupu 1.0.2
   7  
   8  Partially supporting other browsers in Kupu
   9  -------------------------------------------
  10  
  11  When the client is using a browser that is not supported in Kupu, currently 
  12  the results are unpredictable, but quite certainly not graceful. Kupu does
  13  *not* try to degrade in older browsers, it will just not work. The reason
  14  nothing has been added to Kupu to make it for instance show a textarea where
  15  the iframe would have been, is that it's almost impossible to write a good
  16  solution using the JavaScript techniques Kupu uses, since in Kupu' setup
  17  (where the HTML contains part of the editor, unlike systems where the editor
  18  pane isn't configurable and is added to the document using document.write)
  19  it would mean elements should be removed from the page, which may not be 
  20  possible using JavaScript or CSS since those technologies may not even be
  21  available.
  22  
  23  What to do then?
  24  ----------------
  25  
  26  The only proper solution to create a feel of 'graceful degradation' is by
  27  serving different pages according to the HTTP UserAgent header. A script
  28  on the server should try to figure out what browser the client is using (well
  29  actually it just needs to know if it's one of the browsers supported by Kupu)
  30  and if it's an Kupu capable one send the Kupu page, and if it's not, it should
  31  serve a page containing some fallback form or so. Since this process differs
  32  a *lot* from server to server, we will not provide a sample implementation,
  33  but instead we will try to tell how to create one yourself.
  34  
  35  First step: is the client Kupu capable?
  36  ---------------------------------------
  37  
  38  When you're going to write a script to serve different pages to different 
  39  clients, you will probably want to examine the HTTP 'UserAgent' header. This
  40  is a header the client sends along with the request, that contains information
  41  about the user agent (browser) the client is using. The browser is supported 
  42  if:
  43  
  44      - the string starts with 'Mozilla'
  45      - the string contains one of the following elements: 'IE 5.5', 'IE 6' (the
  46          part after 'IE ' should be higher than 5.5 after a convertion to 
  47          float) for Internet Explorer or one of: 'rv:1.3.1', 'rv:1.4', 'rv:1.5', 
  48          'rv:1.6' (the part after 'rv:' should be higher than 1.3.1 after 
  49          conversion to float) for Mozilla and Netscape Navigator.
  50          
  51  If the UserAgent string matches those criteria, the browser is supported. Note
  52  that that doesn't necessarily mean that Kupu will work: the client must have
  53  JavaScript enabled as well, and the supported browsers all allow the client to
  54  turn it off. However, Kupu will (XXX currently *should*!) provide some feedback
  55  to the client about what can be done to get Kupu to work.
  56  
  57  Second step: create a response
  58  ------------------------------
  59  
  60  The second step will be to create a response suitable for the client's user 
  61  agent. In most cases there will be 1 response for Kupu capable browsers (the 
  62  Kupu page) and 1 for non-capable ones. The one for non-supported browsers will
  63  probably contain a form and send the contents of some textarea that contains 
  64  the HTML that would normally be edited in the Kupu iframe to a script on the
  65  server that cleans it up (since Kupu is not available the server should do the
  66  cleanup by itself!) and saves it. The page will probably be a normal HTML form
  67  without too much fancy stuff, since the client's browser may well be one that
  68  doesn't know how to display fancy stuff anyway.
  69  
  70  Third step: process the response
  71  --------------------------------
  72  
  73  The last step will involve writing a script to process the data coming from 
  74  the form. The script will have to receive its data in a POST request, since 
  75  plain HTML forms don't provide PUT support. The script will probably look a 
  76  lot different from the one that saves Kupu' output, so it's advised to not use 
  77  the same script for handling both form output and Kupu, but instead to write
  78  a new one that handles only one task. The goal of both scripts will be the 
  79  same, however: make the content ready for storage and store it.
  80  
  81  And that's it
  82  -------------
  83  
  84  And basically that's it: now if a non-capable browser requests a page, it will
  85  receive something it can handle, the page will (probably) contain only the
  86  most basic HTML elements, and it will use one of the most basic ways of 
  87  sending data to the client, HTTP POST. The proposed way is not easy to 
  88  implement, since it requires a lot of effort from integrators of Kupu compared
  89  to other systems, but it will allow flexibility and configurability without
  90  making concessions in flexibility and technologies chosen (Kupu won't have to
  91  resort to document.write and customization can be done in the HTML rather than
  92  having to hack background colors, button images etc. in the JavaScript).