search

cretz / software-ideas

85 stars 0 forks source link

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

Open cretz opened 5 years ago

cretz commented 5 years ago
paulcmal commented 5 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 5 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 5 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).

samsquire commented 4 years ago