Annotation of kupu/doc/OLDBROWSERS.txt, revision 1.1
1.1 ! dwinter 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).
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>