ideas-computer-jasper-jasperHtml5Basic

since Jasper won't be ready until the far future if ever, unlike most projects, i think it's safe to assume that almost all of our potential users will have HTML5-compatible browsers by then. however, we do want to make sure:

1) not to use parts of HTML5 that aren't very broadly supported by browsers of that time 2) not to use parts of HTML5 that aren't easy to implement and are unnecessary

(2) is because if we really start to bake HTML5 into the Jasper tooling, then we want to be able to work with it from Jasper, which means writing Jasper libraries to work with it, and we don't want to bother with supporting obscure not-really-needed HTML5 features; and also because by that time there will be other existing text-mode tools etc with partial support for HTML5.

so what is 'HTML5 Basic'? it's tough to say. HTML5 is just an update of HTML, but the HTML standard is already complicated and bloated imo (not anyone's fault, this is expected for a practical standard). The W3C modularized HTML5 into a bunch of different standards, but this doesn't mean that everything else is unimportant, e.g. i expect that the vast majority of browsers will also support CSS and JS and SVG. Afaict the HTML5 standard doesn't come with 'profiles' that tell implementors: if don't have time to implement the whole thing, here is the 'core', implement that first (there is something called 'profile' WITHIN the standard but i think it's different).

so maybe we should define our own 'Jasper HTML5 Basic'. But i don't know anything about that stuff so i am reluctant to do so. Otoh, any sort of jasper project tooling architecture guidelines which restrict which HTML5 constructs we are allowed to use is a de-facto HTML5 Basic anyways, so maybe we'll end up having to do this whether or not i feel qualified to participate.

note that for a 'Jasper HTML5 Basic', we have different goals than browser-oriented standards; we aren't concerned with our subset is sufficient to read even a small minority of extant popular web pages; we are only concerned with having a sufficiently large subset to permit us to do what we feel we need to do in our HTML5-based tools. So, our Scratch/Logo/Hypercard-ish IDE might make it easy to generate HTML5 containing only these constructs; but this isn't to say that web frameworks for professional webdevs will be bound to using only this subset, they will probably be using toolchains more like Rails/Django that let you emit whatever HTML you want.