Strict HTML+CSS Subset For Text Friendliness (Terminals or Documents)

cretz commented 6 years ago

Start with very few pieces of HTML and CSS, strictly specified on what is accepted
Initially accept the limitation of no JS
Could be called "Narrow HTML" or "nhtml"
Since it's a strict subset, it can render in normal browsers and we don't want to change the content type or doctype decl
- I think the best way is requiring a valueless data attribute on html, and a strict html start requirement
- Strict document byte start rule: <!doctype html> + whitespace (only '\r\n\t ', max 10 chars) + <html data-nhtml ... (i.e. the data-nhtml attribute must be the first attr on the first element which is html)
Extremely strict validation. Not forgiving like standard HTML...implementations may choose to flat out not render invalid pages
- Easily validated since there is no JS
- We want this because unlike HTML and other specs, the goal is easy renderer implementation instead of easy to write (though still reasonably easy to write). Also, it is expected new docs are written to conform to this spec, it is not built to accept existing ugly docs.
- Make sure to specify which entity references are accepted (probably just the few xml ones, the numeric unicode refs, and a couple others e.g.   that are common enough to not want to use e.g.  )
- Force closing everything, so void elements, e.g. <img> becomes <img/> (but of course </img> is not allowed per the html5 spec)...or maybe disallow slash in void elements...have to weight html spec preference vs friendliness to xhtml/xml parsers (but definitely non-void elements require explicit end tags per the spec)...whichever way is chosen, it must be enforced, both ways are not accepted.
Need initial impl
- Likely in Rust w/ C FFI iface for use by everyone (html5ever helps here)
- Easy to impl in other langs tho
Limits of the terminal and/or text documents define what CSS can be supported
- Only support simple selectors and be very strict on the values you support
- We like to be strict here unlike HTML, so we don't support color: red, color: #ff0000, and color: rgb(255, 0, 0) all together. Instead we will only support one way of doing things (probably hex). rgba seems like it's ideal since it can specify more levels of transparency, but this is a limited set anyways, so the trailing two hex chars can specify transparency (well, IE doesn't support that, we'll see if we even allow transparency)
- I know I could use grid media queries and ignore the rest, but I need to be confident in what I parse
Intentionally not using PDF, markdown, latex, etc because I want html compat and some interactivity ala forms

paulcmal commented 6 years ago

Wow. I've been thinking about this for a while but didn't think it through as much as you did! Thank you :heart:

Only support simple selectors

Any ideas what you mean by that? Personally, I'm a 100% against client-side scripting ordered by the remote server (usually Javascript), but I think the current CSS selectors specs (servo implementation) are really good to easily produce any kind of layout. Are you afraid implementing all the selectors would take too much time?

Or that it would be a performance burden on the client? Personally, i don't think it's wrong for clients to support different subsets of the selectors as long as these differences are standardized. For instance, take a CSS-only collapsable responsive menu: a desktop browser may implement the :hover property to display a submenu, while a mobile browser or a tui browser may rely on labels (and hidden checkboxes) to pop the submenu when clicked. Maybe it would help to think about what kind of patterns/functionalities should be supported and then figuring out the relevant subset of CSS?

ff0000 (…) the trailing two hex chars can specify transparency (…) IE doesn't support that

Having transparency effects over your content and relying on that is already pretty wrong (less readable to millions of people when it works, not readable when it doesn't). So imo transparency not supported in some browsers is not a big deal.

I know I could use grid media queries and ignore the rest, but I need to be confident in what I parse

Not sure what you mean, but supporting flexbox/grid specs, along with media queries, margin/padding and display inline/inline-block/block will already get you pretty far in what you can build! :)

cretz commented 6 years ago

Any ideas what you mean by that? [...] Are you afraid implementing all the selectors would take too much time?

Basically, yes. Simplicity of implementation is more important than features for this idea at least. Of course it's just an idea and can be changed in any way by anyone. In general the main rule would be to add as needed instead of support from the onset. And I would only want to support what could have value from a terminal. So I'd probably exclude all pseudo-classes initially.

Maybe it would help to think about what kind of patterns/functionalities should be supported and then figuring out the relevant subset of CSS?

My main use case was non-interactive documents in terminal or browser or whatever. I just want something really easy to implement. So chosen CSS would be layout driven as opposed to advanced visuals and interactivity.

So imo transparency not supported in some browsers is not a big deal.

Agreed, but even less of a deal is not having transparency here I think, again at least for an MVP.

Not sure what you mean, but supporting flexbox/grid specs, along with media queries, margin/padding and display inline/inline-block/block will already get you pretty far in what you can build! :)

Yup, that's basically it. I would have to dig if/when I actually implemented this, but I'd like to only support flex as an option for display as opposed to other items, but those kinds of decisions can only come through use cases. Same with media queries, I would not want the visual result to be conditional on anything.

cretz commented 6 years ago

Began putting more thoughts on paper at https://github.com/cretz/narrow ...not sure I'll ever complete this or anything. Also, I hadn't read AMP guidelines until now, but there is definitely some overlap (and definitely some distinction esp wrt ease of renderer implementation).

ghost commented 4 years ago

Simpler rendering of web pages is implemented as Google's AMP and Telegram's Instant View.
- There is also WAP and XHTML Mobile which is a stripped down HTML.
There is also a few lightweight HTML renderers.

cretz / software-ideas

Strict HTML+CSS Subset For Text Friendliness (Terminals or Documents) #92

ff0000 (…) the trailing two hex chars can specify transparency (…) IE doesn't support that