[Edbrowse-dev] Render

[Edbrowse-dev] Render

[Karl Dahlke]

Well this is thinking ahead to future versions of edbrowse,
with some of the anticipated redesign.
I'm thinking out lout if you will.

We want to build a tree of javascript objects, first built from html,
then perhaps modified by javascript functions, or even onclick or onchange
code as you interact with the web page.
Then a render function traverses this tree and builds the text buffer that you read.
This render function is called after every javascript invokation,
because you never know what javascript might do.
Add new paragraphs, tables, build new option lists, etc.
This is where we are headed,
and I was almost tempted to start writing render.cpp,
which would not interfere at all with anything going on now,
just a separate file with a function not currently called,
but intended for use in the future.
I was going to copy html.cpp to render.cpp,
and create the same text buffer, but not from html tags, rather from the
tree of javascript objects.
So I would step through the members of each object,
and if it's a text object paste the string into the growing buffer,
and for some other object like a form descend into that object
and do the same thing recursively, generating tags and/or text as we go.
So I start to picture thousands of lines of C++ code stepping through object members,
and rooting object pointers and rooting strings etc, and then it hits me.
A great idea!
Write render() as a javascript function, not in C.
Then just execute render() entirely in javascript.
Use document.write to crank out the text buffer,
and postprocess it at the end to break up long lines just like we do today.
No rooted object pointers, no rooted strings, it just runs.
And it runs the same way even if we switch to another js engine some day.
Completely portable.
So render.cpp is mostly a long string that is the render() function
in javascript, and I just pass it to the js engine for execution,
then the resulting document.write string is the text buffer.

Pretty slick, eh?

As time permits I may start to outline this javascript render function.
This requires some conventions about the object tree,
paragraph objects, text objects, etc; any enhancements
we need to make to dom, but all this has to be settled no matter
how we do it.
Render() will be a nontrivial, recursive javascript function,
but much cleaner and easier than the C counterpart would be.

Karl Dahlke

Re: [Edbrowse-dev] Render

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]

On Fri, Feb 28, 2014 at 11:43:09AM -0500, Karl Dahlke wrote:
> Well this is thinking ahead to future versions of edbrowse,
> with some of the anticipated redesign.
> I'm thinking out lout if you will.
> 
> We want to build a tree of javascript objects, first built from html,
> then perhaps modified by javascript functions, or even onclick or onchange
> code as you interact with the web page.
> Then a render function traverses this tree and builds the text buffer that you read.
> This render function is called after every javascript invokation,
> because you never know what javascript might do.
> Add new paragraphs, tables, build new option lists, etc.
> This is where we are headed,
> and I was almost tempted to start writing render.cpp,
> which would not interfere at all with anything going on now,
> just a separate file with a function not currently called,
> but intended for use in the future.

Yeah, I can see how this'd work.

> I was going to copy html.cpp to render.cpp,
> and create the same text buffer, but not from html tags, rather from the
> tree of javascript objects.

Hmmm, I wonder if we want to try and keep it away from javascript specifics, i.e.
develop a generic DOM structure which we can then plug into with js or whatever.

[snip]
> So render.cpp is mostly a long string that is the render() function
> in javascript, and I just pass it to the js engine for execution,
> then the resulting document.write string is the text buffer.
> 
> Pretty slick, eh?

How'd this work with forms, event handlers and all the associated machinary?

> 
> As time permits I may start to outline this javascript render function.
> This requires some conventions about the object tree,
> paragraph objects, text objects, etc; any enhancements
> we need to make to dom, but all this has to be settled no matter
> how we do it.
> Render() will be a nontrivial, recursive javascript function,
> but much cleaner and easier than the C counterpart would be.

Hmmm, I can see the thought process here,
and I was thinking along the same lines a couple of days ago.
However, the more I think about it the more I think it's potentially not the
best direction for edbrowse since it places a lot of dependancy on something
beyond our control, i.e. the stability or otherwise of a js library.
I also wonder if this'd work in terms of browsing a web page without js, or one which defines its own render function.
Before you ask, I'm fairly sure with the increasing amount of js-driven
gui-style webpages, I could find at least a few
pages with a render() call already.

The kind of model I propose is one inwhich html parsing becomes the creation of
these generic objects, which are also created by javascript (but not stored in
the js universe apart from via wrappers),
and then rendered using a render function called when the tree is updated
(using an update function etc).

I'm fairly sure this'd be possible, and probably simplify things.
In addition there'd be no more rooting required in this system than in the existing
one (object properties go into a list, or hash map,
and are heap rooted on creation etc).
As I said, this needs more thought, but would also mean the failure case becomes
a function which goes through the tree destroying all the js data and then
destroys the context.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] Render

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> However, the more I think about it the more I think it's potentially not the
> best direction for edbrowse since it places a lot of dependancy on something
> beyond our control, i.e. the stability or otherwise of a js library.

True, they're all moving targets.  On the other hand, we're pretty much
tied to a JS library, so we're going to have to deal with its possible
instability anyway.
To me, the render-in-JS idea does seem pretty slick.

> I also wonder if this'd work in terms of browsing a web page without
> js,

In the non-JS case, the only thing we ever call is render.  We don't
evaluate scripts or call form handlers from the page.

> or one which defines its own render function.

That's easy.  Just call it edbrowse_render, to prevent namespace
conflicts.  Still, we have to make sure that this function can't be
overwritten by some script.

-- Chris

[Edbrowse-dev] Render

[Karl Dahlke]

> Hmmm, I wonder if we want to try and keep it away from javascript specifics,

I don't think you can, really, we always have to support javascript,
in whatever its form and syntax and semantics, we're always in there,
in the heart of it,
so why not write render in the language that we know we have to support,
stepping through all the objects that we know we have to have
corresponding tags for.
I don't see the advantage of transmuting all this to another tree in another
home-grown language and then transmuting it back as necessary
to work with javascript.

Also the tree is mostly made for us already.
The form object contains an element array.
This array holds the input tags.
Each input tag has a value and checked field and default,
and if it is a select, it has an array of options,
and each option has a checked field and value, and so on,
all that tree structure is there in javascript,
and has to be there or we aren't doing our job,
so render can just trace it as a javascript function.
The only thing we need to add is a text object.
If there is nothing on the web page but hello world,
no tags, no nothing,
we would have to invent a <P> paragraph tag or some such
to hold the text.
So yes some tweaking on our part,
but I do think much of the tree is already built in js and has to be so
and will always be so, so why not live in that world
when translating the tree back into a text buffer to browse.

> How'd this work with forms, event handlers and all the associated machinery?

I mentioned that forms already build a fairly substantial tree
of javascript objects for us.
It's all in place today.
And so do tables, with rows under tables and elements under rows,
and so on.
I think I implemented tables rows and cells as a js tree.
I was supppose to.
Anyways, an event handler is a function under a tag,
which becomes a js function under the corresponding object for that tag.
Just another leaf on the tree.
Nothing special here, just another member of that object.
And I already do this today for onsubmit onreset onchange onclick.
So again the js tree is already there.
We have to traverse it, and it's easier to traverse in js itself
then in any other outside language such as C.

> it places a lot of dependancy on something
> beyond our control, i.e. the stability or otherwise of a js library.

Well I'd be writing render() in javascript itself, not dependent on any library.
As long as there is a call to
executeJavascriptCode(const char *code)
then we're ok.

The language of js, i mean for loops and if statements etc, isn't going to change.
The objects in the js tree might change, but probably expand in a backward compatible way,
and guess what, we have to support all those changes anyways.
>From html to objects and the semantics of those objects,
from start to end.
And render would have to support the new objects and tags,  whatever language it is written in.
So it would be easiest if it was written in js where the tree lives.
I'm thinking so anyways.


Karl Dahlke

Re: [Edbrowse-dev] Render

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 4468 bytes --]

On Fri, Feb 28, 2014 at 03:01:35PM -0500, Karl Dahlke wrote:
> > Hmmm, I wonder if we want to try and keep it away from javascript specifics,
> 
> I don't think you can, really, we always have to support javascript,
> in whatever its form and syntax and semantics, we're always in there,
> in the heart of it,
> so why not write render in the language that we know we have to support,
> stepping through all the objects that we know we have to have
> corresponding tags for.
> I don't see the advantage of transmuting all this to another tree in another
> home-grown language and then transmuting it back as necessary
> to work with javascript.

I wasn't thinking in terms of a home-grown language exactly,
more an expanded concept of our existing html tags.

> Also the tree is mostly made for us already.
> The form object contains an element array.
> This array holds the input tags.
> Each input tag has a value and checked field and default,
> and if it is a select, it has an array of options,
> and each option has a checked field and value, and so on,
> all that tree structure is there in javascript,
> and has to be there or we aren't doing our job,
> so render can just trace it as a javascript function.
> The only thing we need to add is a text object.
> If there is nothing on the web page but hello world,
> no tags, no nothing,
> we would have to invent a <P> paragraph tag or some such
> to hold the text.

We're basically going to have to parse the page,
wrap things in new tags then hope they don't break the existing html if any.

> So yes some tweaking on our part,
> but I do think much of the tree is already built in js and has to be so
> and will always be so, so why not live in that world
> when translating the tree back into a text buffer to browse.

Primarily because I know of no way of protecting this js render function from
being zapped by an unfortunately crafted page.
At the moment if js does stupid things and breaks the js dom that's not nice 
if it completely destroys our method for rendering the buffer that's
not only difficult to debug but also means you end up with an empty page.

> > How'd this work with forms, event handlers and all the associated machinery?
> 
> I mentioned that forms already build a fairly substantial tree
> of javascript objects for us.
> It's all in place today.
> And so do tables, with rows under tables and elements under rows,
> and so on.
> I think I implemented tables rows and cells as a js tree.
> I was supppose to.
> Anyways, an event handler is a function under a tag,
> which becomes a js function under the corresponding object for that tag.
> Just another leaf on the tree.
> Nothing special here, just another member of that object.
> And I already do this today for onsubmit onreset onchange onclick.
> So again the js tree is already there.
> We have to traverse it, and it's easier to traverse in js itself
> then in any other outside language such as C.

I agree that this is the easiest option,
but I'm still unsure how robust this'll be and also how this plugs into the
existing machinary. For example how will the i and g commands work?

> > it places a lot of dependancy on something
> > beyond our control, i.e. the stability or otherwise of a js library.
> 
> Well I'd be writing render() in javascript itself, not dependent on any library.
> As long as there is a call to
> executeJavascriptCode(const char *code)
> then we're ok.
> 
> The language of js, i mean for loops and if statements etc, isn't going to change.
> The objects in the js tree might change, but probably expand in a backward compatible way,
> and guess what, we have to support all those changes anyways.
> From html to objects and the semantics of those objects,
> from start to end.
> And render would have to support the new objects and tags,  whatever language it is written in.
> So it would be easiest if it was written in js where the tree lives.
> I'm thinking so anyways.

I guess I'm not saying that theoretically this isn't a nice idea,
but I'm really worried how reliable this'll be and how it'll cope with the
insanity that one sees on the web. In addition,
what happens to our ability to render the buffer when js blows up
mid-execution, before we can render things and the context goes away?

Also, how are you going to make this function called every time js does anything?

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] Render

[Karl Dahlke]

> Also, how are you going to make this function called every time js does anything?

Already done.
jSyncup is called before every js action, and jsdw is called afterword.
It's already bracketed.
And we have to do that anyways, to see what changes js made to our buffer
and report them back to the user.
These are things you just "see" in a regular browser.
"Oh - I clicked this button and now there's something new there."
We have to report it, and I made a first stab at it,
but we have to do better.
Like jsrt when you push the calc button it tells you that a line was updated.

> Primarily because I know of no way of protecting this js render function from
> being zapped by an unfortunately crafted page.

Like malice?

> At the moment if js does stupid things and breaks the js dom that's not nice
> if it completely destroys our method for rendering the buffer that's
> not only difficult to debug but also means you end up with an empty page.

Yes, a great point made in one sentence.
You couldn't turn js completely off, as you do today,
it would still have to be on long enough to build the objects from html like today,
but not run any scripts, then traverse the objects to render the page,
which is a funny flavor of off, not entirely off.
And if js was off because some other session hogged all the js memory,
well then we're up the creek eh?
Really annoying that the js pool is a fixed size.
So yes there's more to think about here.
Damn, I really liked the idea too!
Well we have time to mull it over and talk it out.

I found this in a tutorial long ago and bookmarked it.
It's the kind of thing we should support.
See how tables and cells and paragraphs and just about anything
on the web page can be built by javascript, not just by html tags?

https://developer.mozilla.org/en/docs/Traversing_an_HTML_table_with_JavaScript_and_DOM_Interfaces

Most web pages aren't that crazy but some are, and more and more web pages
at least build little partswith js,
like building the secondary menu based on your selection in a primary menu.
That happens all the time.
I wrote such a website for my work; I wrote a website
I couldn't even use with edbrowse. Ironic.
Anyways, I wonder, how long can we say
"Gee we need to render html even if js won't run",
will the day come when there just aren't many web pages left
that have any meaning without js?
Not trying to cause trouble, just wondering.
So anyways all this dynamic creation, perhaps well after the page is parsed,
perhaps because you pushed a button,
all this dynamism we must support.

html tags become js objects.
js scripts make more objects or change these objects.
js objects become things on the screen, or in our case the text buffer.

User pushes a button.
js function makes new objects or changes the objects.
js tree of objects implies a new buffer.
compare with the old buffer and report any differences.
Wait for next user input or action.


Karl Dahlke

Re: [Edbrowse-dev] Render

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 8931 bytes --]

On Fri, Feb 28, 2014 at 06:32:38PM -0500, Karl Dahlke wrote:
> > Also, how are you going to make this function called every time js does anything?
> 
> Already done.
> jSyncup is called before every js action, and jsdw is called afterword.
> It's already bracketed.
> And we have to do that anyways, to see what changes js made to our buffer
> and report them back to the user.
> These are things you just "see" in a regular browser.
> "Oh - I clicked this button and now there's something new there."
> We have to report it, and I made a first stab at it,
> but we have to do better.
> Like jsrt when you push the calc button it tells you that a line was updated.

Yeah, I thought I was missing something.

> 
> > Primarily because I know of no way of protecting this js render function from
> > being zapped by an unfortunately crafted page.
> 
> Like malice?

That (which is probably unlikely), or a web developer choosing render as a
perfectly reasonable name for some bit of shiny js.
The same problem also exists with edbrowse_render, though much reduced,
particularly if the popularity of edbrowse increases.
This is because of the tendancy of developers to create browser-specific js,
and if anyone did this for edbrowse (again unlikely but still)
they may well use edbrowse_<whatever> for a function name.

I know that the 2nd one seems like a particularly unlikely issue to encounter
but one of the motivations behind the move to mozjs24 and the js improvements
in general is reliability and security and there's just so much damage one
could do by overriding the render function, i.e. form submissions etc.
Or (note,
completely untested so excuse my rusty js syntax):
<script type="text/javascript">
function render()
{
var x = 0;
while (x < 10)
{
// complex code to do fancy things
x++;
// more complex code including something like
var para = document.getElementsByTagName("p")[x--];
var txt = document.createTextNode("This is test text");
para.appendChild(txt);
}
}
</script>
<form>
<input type="button" value="render javascript test text" onclick="render()" />

This render function has a relatively plausable bug (if you fill in the complex
code sections with something) which creates an infinite loop.
This wouldn't break anything as long as the user
never clicked the "render javascript test text" button normally,
however it's overridden the proposed render function and so gets called 
automatically.

> > At the moment if js does stupid things and breaks the js dom that's not nice
> > if it completely destroys our method for rendering the buffer that's
> > not only difficult to debug but also means you end up with an empty page.
> 
> Yes, a great point made in one sentence.
> You couldn't turn js completely off, as you do today,
> it would still have to be on long enough to build the objects from html like today,
> but not run any scripts, then traverse the objects to render the page,
> which is a funny flavor of off, not entirely off.
> And if js was off because some other session hogged all the js memory,
> well then we're up the creek eh?
> Really annoying that the js pool is a fixed size.
Yes and no.  It's a hard limit on js memory usage which, given some of the buggy js out there, is a good thing.  It's just unfortunate in our case potentially.

> So yes there's more to think about here.
> Damn, I really liked the idea too!

So did I until I looked into it. I even went as far as exploring pure js DOM
implementations like env.js (apparently spidermonkey versions exist)
whilst thinking through all the implications.

Whilst we're on the subject of js reliability,
I'd really like to know how browsers test when scripts have gone into infinite 
loops, or have generally broken (i.e.
firefox (I think) has a "A script on this page has stopped responding" error).
This'd be another nice addition to edbrowse.

> Well we have time to mull it over and talk it out.

Agreed.

> I found this in a tutorial long ago and bookmarked it.
> It's the kind of thing we should support.
> See how tables and cells and paragraphs and just about anything
> on the web page can be built by javascript, not just by html tags?
> 
> https://developer.mozilla.org/en/docs/Traversing_an_HTML_table_with_JavaScript_and_DOM_Interfaces
> Most web pages aren't that crazy but some are, and more and more web pages
> at least build little partswith js,
> like building the secondary menu based on your selection in a primary menu.
> That happens all the time.

Yeah. I've just read a bit of this tutorial.
I knew you *could* do that with js but I'd never actually seen the code
to do it before.

> I wrote such a website for my work; I wrote a website
> I couldn't even use with edbrowse. Ironic.

Yeah, just a bit.

> Anyways, I wonder, how long can we say
> "Gee we need to render html even if js won't run",
> will the day come when there just aren't many web pages left
> that have any meaning without js?
> Not trying to cause trouble, just wondering.
[begin opinionated speculation]
No, static html will always exist, and I can point to many sites where the js
merely serves to run google analytics etc,
and which won't be changing any time soon.
Indeed, I talked to someone who develops software (web-based and backend stuff)
and he was saying about a project he was involved in to create a js-free
version of a highly js-intensive site.
He found it quite interesting that, with careful design,
he was able to achieve a nice user experience without all the shiny js stuff.
That was last year.

In addition, it's certainly encouraged practice in web accessibility to provide
a largely js free version of the site to work in cases where js is unavailable
or the js-driven interface is not accessible to screenreader users.
Unfortunately with the current drive for ever more js and shiny,
such practises have been forgotten in some cases,
however I've seen definite improvements in some sites (which were more than
negated by the updates made to others).
The basic point I'm trying to make here is that I think it'll continue to be
important to render pages without js as long as the html standard doesn't start requiring js
in order to parse and render.
[end opinionated speculation]
> So anyways all this dynamic creation, perhaps well after the page is parsed,
> perhaps because you pushed a button,
> all this dynamism we must support.

Agreed, and then there's AJAX (or whatever it's called when you actually get a
JSON response instead), and all the dynamically created stuff from that executing.

> html tags become js objects.
> js scripts make more objects or change these objects.
> js objects become things on the screen, or in our case the text buffer.
> 
> User pushes a button.
> js function makes new objects or changes the objects.
> js tree of objects implies a new buffer.
> compare with the old buffer and report any differences.
> Wait for next user input or action.

Yeah. I think in order to get this to work in a nice way we really need to
rethink how we create our DOM, i.e. I think we probably need to change the tag
array to a tag tree then work from there.
That'll allow us to write element creation as a tag creation function
and appendchild (not sure of case) as a tree insertion.
When we parse tags we re-use the C versions of these tag creation and tree
insertion functions, and provide js wrappers for them.
There are other ways I'm contemplating for handling tag properties (like a
string to something hash map) which would allow JS wrappers to become more
generic (I think).
I *definitely* don't want to create a ridiculously abstract way of creating a
DOM with classes, derived classes etc to create tag objects, far from it!
I'm just trying to come up with an extension to the existing html tag structure
which would allow it to work as a tree and store tag properties.
Once we have this, I think the JS stuff will probably get much simpler as we'll
just be creating wrappers rather than dealing with js GC weirdness, i.e.
getElementByTagName only has to create the (rooted?)
js objects when called, other than that the DOM stays away from the GC.
These objects would only need to concist of small wrapper functions which
plugged into the existing DOM, rather than copying text etc.
I think this is probably not a million miles away from what we currently have,
with the exception of a tree structure and generic property handling.
Also, thinking in terms of optimisation, if a child of a tag is changed,
a flag could be set in its parent (or a pointer to the parent added to a list)
meaning rendering need only start from that child,
rather than re-rendering the entire tree possibly.
I'm not sure how plausable this sounds,
but I think this is where we need to head for.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] Render

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

>> > At the moment if js does stupid things and breaks the js dom that's not nice
>> > if it completely destroys our method for rendering the buffer that's
>> > not only difficult to debug but also means you end up with an empty page.

Can't we make the render function (or edbrowse_render) read-only?  I'm
pretty sure we can.  But maybe this still wouldn't solve all the
problems.

> I'd really like to know how browsers test when scripts have gone into infinite 
> loops, or have generally broken

That's the halting problem, and it isn't computable.  There's no way to
truely detect whether an arbitrary script has failed.  I suspect they
just use a timeout, but I haven't looked at the source.
We should be able to call alarm before JS execution and let SIGALRM
interrupt JS when the timeout is reached.  But I can't guarantee that
Spidermonkey will not call sleep.  Mixing calls to alarm and sleep is a
bad idea.

> No, static html will always exist, and I can point to many sites where the js
> merely serves to run google analytics etc,
> and which won't be changing any time soon.

Yes, I'm pretty sure static html will always be with us, because a lot
of written content is basically static.
Also, lots of people are viewing the web with tablets and phones, and
I've read that JavaScript sucks massively on mobile devices.
Unfortunately, blogs created on Google's Blogger platform with the
default template are unreadable without JavaScript.  You needed JS
enabled to read content that is static.  They weren't readable with
edbrowse, and last time I looked, they weren't even very nice to read in
chrome with chromevox or firefox with a screen reader.  Deedra had one
of these, and she couldn't easily read it in firefox.That was early last year.  Maybe Google has fixed their default template
by now.

-- Chris

Re: [Edbrowse-dev] Render

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

On Wed, Mar 12, 2014 at 09:57:36AM -0700, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> >> > At the moment if js does stupid things and breaks the js dom that's not nice
> >> > if it completely destroys our method for rendering the buffer that's
> >> > not only difficult to debug but also means you end up with an empty page.
> 
> Can't we make the render function (or edbrowse_render) read-only?  I'm
> pretty sure we can.  But maybe this still wouldn't solve all the
> problems.

I'm not too sure we can. If so, any chance of linking to the docs as I've yet to find any which mention read-only functions.

> > I'd really like to know how browsers test when scripts have gone into infinite 
> > loops, or have generally broken
> 
> That's the halting problem, and it isn't computable.  There's no way to
> truely detect whether an arbitrary script has failed.  I suspect they
> just use a timeout, but I haven't looked at the source.

Yeah, I know about the halting problem,
which is why I was unsure how firefox etc kill supposedly broken scripts.
I think the time out is probably the approach used since I've seen on a couple
of occasions scripts which have triggered this when in reality they've just
been taking a *long* time to do anything.

> We should be able to call alarm before JS execution and let SIGALRM
> interrupt JS when the timeout is reached.  But I can't guarantee that
> Spidermonkey will not call sleep.  Mixing calls to alarm and sleep is a
> bad idea.

Yeah, but I'm unsure how else we can do this within a single thread.
I wonder if smjs has any hooks we can use for this kind of thing.
Incidentally, did you know that when one writes an infinite recursive function,
smjs seems to kill it at a certain limit without throwing an error,
at least not one which edbrowse displays?
The limit seems to be 60000 on my machine.

> > No, static html will always exist, and I can point to many sites where the js
> > merely serves to run google analytics etc,
> > and which won't be changing any time soon.
> 
> Yes, I'm pretty sure static html will always be with us, because a lot
> of written content is basically static.
> Also, lots of people are viewing the web with tablets and phones, and
> I've read that JavaScript sucks massively on mobile devices.

It's getting better with the advent of more powerful devices (my friends now
have ones which aren't a million miles away from being more powerful than my desktop!).

> Unfortunately, blogs created on Google's Blogger platform with the
> default template are unreadable without JavaScript.  You needed JS
> enabled to read content that is static.  They weren't readable with
> edbrowse, and last time I looked, they weren't even very nice to read in
> chrome with chromevox or firefox with a screen reader.  Deedra had one
> of these, and she couldn't easily read it in firefox.That was early last year.  Maybe Google has fixed their default template
> by now.

I'm not sure, I hope they fix it if they haven't already.
I remember getting emailed a link to one of these and wondering why it was
broken in edbrowse.
I thought this was a one-off but apparently not.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]