Re: [fossil-users] Browser support
On Mar 18, 2015, at 9:57 AM, Richard Hipp d...@sqlite.org wrote: * canvas is limited in size to 32768 pixels, while graphs sometimes approach one million pixels. I assume you wrote this before seeing my td canvas /td concept. 32 kpx divided by about 20 px per line means you’d need a checkin comment about 1,600 lines long to exceed the limits of canvas. * PNG and SVN are unable to change dynamically in response to browser window resize events. The more I think about the PNG option, the less I like it anyway. I only mentioned it as an option to placate those who think it is reasonable to limit web apps in 2015 to the capabilities of 1995 style browsers. As I said in the original post, we do have dynamic PNG generation code in our main web app, but it dates to about 2000, prior to the existence of canvas and the widespread adoption of SVG in browsers. Our dynamic PNG generation case is much simpler than Fossil’s timeline, so we have no real need to rewrite it. I’m not sure if SVG would show this scaling problem, too. It lets you specify line thickness in px, but sometimes browsers scale absolute px values when zooming. There’s also the HiDPI issue: a HiDPI/retina aware browser is going to second-guess px values. But, I think canvas actually matches Fossil’s needs best. It decouples the drawing from the table layout code, and can be redrawn on window resize events. That will solve the zoomed browser drawing problem, too. You can handle the HiDPI issue in canvas by scaling absolute values by window.devicePixelRatio. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 3/18/15, Warren Young w...@etr-usa.com wrote: The current timeline drawing code is a really nasty hack, abusing HTML in ways not intended by its designers. (E.g. Arrowheads constructed from a ziggurat of black-filled divs.) It is a nasty hack. But it is also the only way we have found so far to achieve the desired visuals using the (rather limited) HTML5 stack. * canvas is limited in size to 32768 pixels, while graphs sometimes approach one million pixels. * PNG and SVN are unable to change dynamically in response to browser window resize events. This recent round of attempts to antialias these div ziggurats appears to have unfortunate side-effects: Note the variable arrowhead offset and the changing line thickness. PNG, canvas and SVG at least are all *intended* for display of diagrams. The varying thicknesses and offset arrowheads seem to be due to your use of zooming. I think if you zoom to 100%, the undesirable artifacts will disappear. The same effect might well result from trying to draw those features using PNG, canvas, or SVG, depending on how the web browser handles zooming. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 3/18/15, Warren Young w...@etr-usa.com wrote: I think you can just piece the graph together one row at a time. HTML has several facilities for stretching graphic elements over the width or height of a td, for example. Pseudocode: td style=“background-image:url(‘row3523.png’); height: 100%” valign=top align=center img src=“box.png” onclick=“javascript:toggleSelection(this)br img src=“arrowhead.png” /td The row PNG would have the lines, and the box and arrowhead PNGs would overlay it, hiding the fact that the line extends underneath. For a 1000-check-in graph, how many PNGs are required? How many server round-trips is that? Or does it use the img src=data:image/gif;base64,R0l in-line image trick? In that case, how many GIFs does the server have to compute in order to render the timeline, and how long will that take on the server side? For all its faults, the current timeline mechanism works with a single HTTP request, has all content in a single HTML file, and is computed quickly and efficiently on the server side. 3. Generate the timeline via canvas. That also requires JS, no? Yes. If you went this route, I think you’d want to let the browser lay out the table, then go in and draw each tdcanvas id=“row3987”/td cell one at a time. the canvas is limited in size to 32768 pixels high Just so it’s clear, a canvas-per-td model makes that limit irrelevant. That could be done. There are a few disadvantages though: (1) No longer works on browsers that lack canvas support. (That is less and less of a problem with each passing year - though it was a significant problem when Fossil was much younger.) (2) It is likely much more complicated than the one-big-graph approach. Currently, of there is a line from the 289th entry up to the 41st entry of the graph, that is a single entry in a table. But with separate canvas, apparently that line now requires entries in 249 different canvas definition tables? Either that, or somehow 249 different canvas renderings need to somehow find out about that one single entry in the global table. (3) The click-two-nodes-to-diff feature might be more difficult to implement. I'm unclear on this. Can events be added to a canvas that fire when a click occurs on a specific element? (4) This is basically a complete top-to-bottom redesign and rewrite of the timeline graph. One wonders if that effort might not be more profitably applied in other areas. The multiple canvas approach does have the advantage that it allows the use of curved and angled lines, whereas the current scheme requires a strict Manhattan geometry. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mar 16, 2015, at 7:06 PM, jungle Boogie jungleboog...@gmail.com wrote: Hi Warren, On 16 March 2015 at 17:50, Warren Young w...@etr-usa.com wrote: There are at least three ways to create the timeline without Javascript. Do you have examples of these three methods? They're self-evident to a practitioner versed in the art. ;) what would a HTML5 Fossil actually look like contrasted with what it is now? What new things would it offer over what doesn't exist now? The current timeline drawing code is a really nasty hack, abusing HTML in ways not intended by its designers. (E.g. Arrowheads constructed from a ziggurat of black-filled divs.) This recent round of attempts to antialias these div ziggurats appears to have unfortunate side-effects: Note the variable arrowhead offset and the changing line thickness. PNG, canvas and SVG at least are all *intended* for display of diagrams.___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mar 16, 2015, at 7:13 PM, Richard Hipp d...@sqlite.org wrote: On 3/16/15, Warren Young w...@etr-usa.com wrote: There are at least three ways to create the timeline without Javascript. 1. Build the timeline as a dynamic PNG on the server side The main difficulty is knowing where to put each node of the graph, since the vertical space between nodes depends on how long the check-in comment is and how it wraps. Yes, I see what you mean. However, I think you can just piece the graph together one row at a time. HTML has several facilities for stretching graphic elements over the width or height of a td, for example. Pseudocode: td style=“background-image:url(‘row3523.png’); height: 100%” valign=top align=center img src=“box.png” onclick=“javascript:toggleSelection(this)br img src=“arrowhead.png” /td The row PNG would have the lines, and the box and arrowhead PNGs would overlay it, hiding the fact that the line extends underneath. I didn't get far enough down this path to investigate the second potential problem: limits on the sizes of GIF/PNG files. PNG dimensions actually go to 2^31 px, but that’s academic, since drawing it all in a single PNG isn’t a good idea. The same is true of the canvas and SVG options: you’d want to draw the graph piece-by-piece in the timelineGraph td elements. Or would it be necessary to bring the image up into segments, with a separate server round-trip and CGI-process invocation for each chunk? That’s one of several advantages to the canvas and SVG options: you can put the code inline within the td element. The only advantage to the PNG option is that you can avoid HTML5 and can run on half-baked browsers like Dillo, but that’s chasing a sub-1% slice of the user base. Is it wrong to think that any browser that does not support JS probably also does not support SVG? JS and SVG are orthogonal. You can have a browser with any of the four combinations of this pair of features. You'll probably want to tie some JS to the SVG for the clickable boxes, but that’s no different from the current situation. I've never worked with SVG, so I don't know its limitations and capabilities. Well, put it this way: SVG is the native file format for Inkscape, which manages to compete fairly well with Adobe Illustrator. Can it create the very tall graphics required by the Fossil timeline? SVG is a vector drawing format. It can be used to create mile-high drawings at 1200 dpi, if you cared to. 3. Generate the timeline via canvas. That also requires JS, no? Yes. If you went this route, I think you’d want to let the browser lay out the table, then go in and draw each tdcanvas id=“row3987”/td cell one at a time. the canvas is limited in size to 32768 pixels high Just so it’s clear, a canvas-per-td model makes that limit irrelevant. Well, I suppose it prevents you from writing a fanfic take-off on the Epic of Gilgamesh in a Fossil checkin comment, but you deserve what you get if you do such a thing. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mar 17, 2015, at 5:01 AM, John Found johnfo...@asm32.info wrote: I know several people, that prefer to disable JS even on new browsers because of security reasons. Unfortunately, the browsers does not allow disabling JS on site base Which browser is this? NoScript pioneered the solution to this problem for Firefox, allowing global JS blocking with per-site exceptions. The popularity of this plugin prompted Mozilla to remove the “disable JS” checkbox from its prefs GUI entirely. Chrome, the most popular browser in the world at the moment, has a similar facility built-in. IE can also do it, via its Zones feature. JavaScript Blocker is essentially NoScript for Safari. NotScripts does it for Opera. That covers 99.mumble% of the web client world. I’m assuming desktop use here, but mobile clients generally don’t have to worry about JS as a security risk to begin with, since all the major mobile OSes are sandboxed to a fare-thee-well. Another observation about such users is that they think that logging-in in fossil will need some kind of registration they are not willing to do. This way they simply never click on login link and never read the instructions on the login page, ending with heap of honey-pot links and not able to navigate the repository. Are we talking about the digital equivalent of cinderblock walls topped with razor wire, dog patrols, armed guards, and helicopters? Some people are simply constitutionally insecure. Fossil can’t fix that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mar 18, 2015, at 10:33 AM, Richard Hipp d...@sqlite.org wrote: For all its faults, the current timeline mechanism works with a single HTTP request, has all content in a single HTML file, and is computed quickly and efficiently on the server side. SVG and Canvas would do that, too, and probably in less code than required by the current div hackery. Can events be added to a canvas that fire when a click occurs on a specific element? Building interactive graphics with raw canvas elements is a fair bit of work, but doable. Basically you have to work out what was clicked given a raw coordinate value, which means you have to remember where on the canvas you drew each box. Or, you can just use a scene graph library like EaselJS, which provides things like the Shape class, which can receive click events: https://github.com/CreateJS/EaselJS EaselJS’s API is based on the ActionScript API for Flash, and it’s quite powerful. Current versions of Adobe Flash Professional use EaselJS when exporting Flash to HTML5. Scene graph libraries provide other benefits, such as a hierarchical display list instead of a raw array-of-pixels, so that you can let the library worry about things like drawing order. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mar 18, 2015, at 10:33 AM, Richard Hipp d...@sqlite.org wrote: Currently, of there is a line from the 289th entry up to the 41st entry of the graph, that is a single entry in a table. But with separate canvas, apparently that line now requires entries in 249 different canvas definition tables? Either that, or somehow 249 different canvas renderings need to somehow find out about that one single entry in the global table. I didn’t respond to this immediately because I wanted to think a bit about it first, so please excuse the second reply. I think the solution is for the Fossil web server to ship a JSON representation of its internal data structure as part of the web page. Then the JS canvas drawing code can iterate over that data structure when drawing its sub-graphs. Think MVC: you’re shipping the timeline model down to the client along with a copy of the view code that turns that model into pixels. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 17/03/15 06:20, Warren Young wrote: On Mar 16, 2015, at 11:15 AM, Richard Hipp d...@sqlite.org wrote: The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. Hi, it’s the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. 1. Build the timeline as a dynamic PNG on the server side, then serve the client a URL to that dynamic PNG. This requires libpng or similar, some line-drawing API on top of that (e.g. libgd, SDL, etc.), and ideally a place to cache the generated PNG so it doesn’t have to be re-generated until a timeline update invalidates it. We actually have code doing this, written before the next two options became widely available. We’ll get around to rewriting it RSN. 2. Generate the timeline server-side as SVG, and serve it inline on the timeline page. Of the mainstream browsers with significant market share, only IE8 doesn’t support SVG: http://caniuse.com/#search=svg The only reason there’s still a significant chunk of IE8 out there is that that’s the last version of IE that will run on XP. No developer should still be running an unsupported 13 year old OS on his desktop anyway. There is an SVG shiv for IE8 - maybe more than one. Some people at large organisation still have support for XP (MS call it custom support or something similar and charge a LOT for it) and may not have a choice. 3. Generate the timeline via canvas. Yes, technically this is one of those spiffy HTML5 features, but it’s actually about as well supported as SVG these days: http://caniuse.com/#search=canvas Only option 1 will work for Tim's favorite browser, Dillo, but…ugh. The effort needed seems excessive to compared to Dillo's user base. Fossil should not *require* any of the latest HTML5 stuff. A few years ago I would have agreed with you, but browsers have come a long way recently, what with all the new competition. I’m all for supporting “ancient” browsers, as long as they still render standard HTML, CSS and JS code correctly. Our own web app finally dropped Firefox 2 support recently, moving the low bar up to Firefox 3, because we found a case where 2 wasn’t doing the right thing with some perfectly reasonable code. I don’t think it’s unreasonable to require a browser released 6 years ago at minimum. We have too many good browsers available these days to be continuing to bend over backwards with browser compatibility hacks. You have to be able to draw some line in the sand, some minimum level of required features. I think IE9 makes a pretty good target. Although it’s only 4 years old now, it was about 3 years behind the rest of the mainstream browser world at the time, in terms of HTML, CSS JS feature compatibility. (Yes, about equal to Firefox 3, Safari 3, and Chrome 1.0!) IE9 is the newest IE that still runs on the oldest supported version of Windows, Vista, which will be in “extended support” for another couple of years. This does rule out XP support for sites unwilling to switch from IE, but I don’t think such people are Fossil’s target market anyway. Incidentally, if you’re looking for ways to test with versions of IE you otherwise wouldn’t have access to, visit: https://www.modern.ie/ You wouldn’t know it from the URL, but it’s actually a Microsoft service, offering legitimate testing versions of Windows pre-loaded with specific versions of IE. An especially nice feature is that it can generate images in any of several VM formats: VirtualBox, OVA (VMware), Hyper-V, Parallels… It is very useful and as far as I am concerned the best thing MS has done for years. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mon, 16 Mar 2015 13:15:00 -0400 Richard Hipp d...@sqlite.org wrote: I agree that Fossil ought to be usable (though perhaps with reduced functionality, such as no timeline graph) even with very old and primitive browsers. Fossil should not *require* any of the latest HTML5 stuff. Certainly it is free to take advantage of those new features if they are available, but Fossil should still be usable without them. It is not only an issue with the old vs new browsers. I know several people, that prefer to disable JS even on new browsers because of security reasons. Unfortunately, the browsers does not allow disabling JS on site base, so even trusted web sites get disabled. On the other hand HTML5 and CSS for these users are OK. Another observation about such users is that they think that logging-in in fossil will need some kind of registration they are not willing to do. This way they simply never click on login link and never read the instructions on the login page, ending with heap of honey-pot links and not able to navigate the repository. -- http://fresh.flatassembler.net http://asm32.info John Found johnfo...@asm32.info ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On Mar 16, 2015, at 11:15 AM, Richard Hipp d...@sqlite.org wrote: The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. Hi, it’s the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. 1. Build the timeline as a dynamic PNG on the server side, then serve the client a URL to that dynamic PNG. This requires libpng or similar, some line-drawing API on top of that (e.g. libgd, SDL, etc.), and ideally a place to cache the generated PNG so it doesn’t have to be re-generated until a timeline update invalidates it. We actually have code doing this, written before the next two options became widely available. We’ll get around to rewriting it RSN. 2. Generate the timeline server-side as SVG, and serve it inline on the timeline page. Of the mainstream browsers with significant market share, only IE8 doesn’t support SVG: http://caniuse.com/#search=svg The only reason there’s still a significant chunk of IE8 out there is that that’s the last version of IE that will run on XP. No developer should still be running an unsupported 13 year old OS on his desktop anyway. 3. Generate the timeline via canvas. Yes, technically this is one of those spiffy HTML5 features, but it’s actually about as well supported as SVG these days: http://caniuse.com/#search=canvas Only option 1 will work for Tim's favorite browser, Dillo, but…ugh. Fossil should not *require* any of the latest HTML5 stuff. A few years ago I would have agreed with you, but browsers have come a long way recently, what with all the new competition. I’m all for supporting “ancient” browsers, as long as they still render standard HTML, CSS and JS code correctly. Our own web app finally dropped Firefox 2 support recently, moving the low bar up to Firefox 3, because we found a case where 2 wasn’t doing the right thing with some perfectly reasonable code. I don’t think it’s unreasonable to require a browser released 6 years ago at minimum. We have too many good browsers available these days to be continuing to bend over backwards with browser compatibility hacks. You have to be able to draw some line in the sand, some minimum level of required features. I think IE9 makes a pretty good target. Although it’s only 4 years old now, it was about 3 years behind the rest of the mainstream browser world at the time, in terms of HTML, CSS JS feature compatibility. (Yes, about equal to Firefox 3, Safari 3, and Chrome 1.0!) IE9 is the newest IE that still runs on the oldest supported version of Windows, Vista, which will be in “extended support” for another couple of years. This does rule out XP support for sites unwilling to switch from IE, but I don’t think such people are Fossil’s target market anyway. Incidentally, if you’re looking for ways to test with versions of IE you otherwise wouldn’t have access to, visit: https://www.modern.ie/ You wouldn’t know it from the URL, but it’s actually a Microsoft service, offering legitimate testing versions of Windows pre-loaded with specific versions of IE. An especially nice feature is that it can generate images in any of several VM formats: VirtualBox, OVA (VMware), Hyper-V, Parallels… ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
Hi Warren, On 16 March 2015 at 17:50, Warren Young w...@etr-usa.com wrote: Hi, it’s the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. Do you have examples of these three methods? Just curious, what would a HTML5 Fossil actually look like contrasted with what it is now? What new things would it offer over what doesn't exist now? just curious. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 3/16/15, Richard Hipp d...@sqlite.org wrote: On 3/16/15, Warren Young w...@etr-usa.com wrote: On Mar 16, 2015, at 11:15 AM, Richard Hipp d...@sqlite.org wrote: The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. Hi, it's the resident pro web app developer checking in again. :) There are at least three ways to create the timeline without Javascript. 1. Build the timeline as a dynamic PNG on the server side, then serve the client a URL to that dynamic PNG. This requires libpng or similar, some line-drawing API on top of that (e.g. libgd, SDL, etc.), and ideally a place to cache the generated PNG so it doesn't have to be re-generated until a timeline update invalidates it. We actually have code doing this, written before the next two options became widely available. We'll get around to rewriting it RSN. The main difficulty is knowing where to put each node of the graph, since the vertical space between nodes depends on how long the check-in comment is and how it wraps. And if the operator resizes the browser window to be narrower or wider, then the comments will wrap at different places and change the spacing. Is there a css fill/sticky option that will shrink/grow that ? If so, it'd be like using a 1x90 image and just declaring it 500x90 so it's stretched, making a bar, no ? I haven't worked in this field for long enough that few paradigms have come-and-gone, but I feel like a gd (or similar) solution isn't far-fetched. -bch I didn't get far enough down this path to investigate the second potential problem: limits on the sizes of GIF/PNG files. Some of the graphs can be *very tall* - hundreds of thousands or perhaps millions of pixels. Is there a limit on the height of a GIF/PNG file? And will browsers successfully render very tall GIF/PNGs. Or would it be necessary to bring the image up into segments, with a separate server round-trip and CGI-process invocation for each chunk? 2. Generate the timeline server-side as SVG, and serve it inline on the timeline page. Of the mainstream browsers with significant market share, only IE8 doesn't support SVG: http://caniuse.com/#search=svg The only reason there's still a significant chunk of IE8 out there is that that's the last version of IE that will run on XP. No developer should still be running an unsupported 13 year old OS on his desktop anyway. Is it wrong to think that any browser that does not support JS probably also does not support SVG? I've never worked with SVG, so I don't know its limitations and capabilities. Can it create the very tall graphics required by the Fossil timeline? 3. Generate the timeline via canvas. That also requires JS, no? Some early versions of Fossil actually did this. The main problem is that the canvas is limited in size to 32768 pixels high. (What was the W3C thinking when they speced this!!!) Lots of timelines are much taller than that. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 3/16/15, Chad Clabaugh chadclaba...@gmail.com wrote: Is there an official list of supported browsers? I've been unable to find any references in the documentation. If not, can one be added? There is no official list. The correct answer, though, should be as many as possible. The idea is to keep the interface conservative and not depend on having the latest trending browser features. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 2015-03-16 12:04, Richard Hipp wrote: Is there an official list of supported browsers? I've been unable to find any references in the documentation. If not, can one be added? There is no official list. The correct answer, though, should be as many as possible. The idea is to keep the interface conservative and not depend on having the latest trending browser features. As someone who likes uses Dillo (a light FLTK browser[1]) and console browsers such as lynx[2]/links/elinks/w3m, and flies with NoScript on Firefox, there have been certain features that appear to require JavaScript. While I expect that full non-JS accessibility is often only a nice-to-have pipedream, if such a list of supported-browsers was created, it would be nice to catalog which parts of Fossil break without JS. -tim [1] http://www.dillo.org/ [2] http://lynx.isc.org/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Browser support
On 3/16/15, Tim Chase fos...@tim.thechases.com wrote: On 2015-03-16 12:04, Richard Hipp wrote: Is there an official list of supported browsers? I've been unable to find any references in the documentation. If not, can one be added? There is no official list. The correct answer, though, should be as many as possible. The idea is to keep the interface conservative and not depend on having the latest trending browser features. As someone who likes uses Dillo (a light FLTK browser[1]) and console browsers such as lynx[2]/links/elinks/w3m, and flies with NoScript on Firefox, there have been certain features that appear to require JavaScript. While I expect that full non-JS accessibility is often only a nice-to-have pipedream, if such a list of supported-browsers was created, it would be nice to catalog which parts of Fossil break without JS. The timeline graph is drawn using JS. Without JS you do not get the very nice timeline graph. I don't see any reasonable way around that. JS is also used for robot defenses. Depending on server settings, users who are not logged in see a honeypot as the href= of anchor tags. Then JS goes through and sets the correct target after mouse movement is detected. This can be circumvented by logging in. Usually logging in as anonymous is sufficient. Click-to-sort on various tables is done using JS. Opening and closing subtrees in the file tree display is done using JS. That's all that comes readily to mind. I agree that Fossil ought to be usable (though perhaps with reduced functionality, such as no timeline graph) even with very old and primitive browsers. Fossil should not *require* any of the latest HTML5 stuff. Certainly it is free to take advantage of those new features if they are available, but Fossil should still be usable without them. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
