5 ms·

> You know.. HTML used to be hyper text. Some links. Add some figures/images, tables. It still is. > But then we 'needed' magazine-like design/layout. Still,

by foofie 3y ago

> You know.. HTML used to be hyper text. Some links. Add some figures/images, tables. It still is. > But then we 'needed' magazine-like design/layout. Still, it was document based, so actually pretty good. Styling is not handled by HTML. It's a separate concern assigned to CSS. For convenience HTML offered default styling. > After that, we tried to shoehorn HTML to an application distribution platform. It's not shoehorned. It's the use case: render documents. A document is a tree of ui elements. It's the same with GUI frameworks like Qt or WPF.

mapreduce 3y ago
> "It still is." It still is but you are missing the point of the thread. HTML still is hypertext, some links, some images, some tables. No doubt about that. But HTML is also so much more than that. The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them. It's like "go implement a new browser" like someone said in this thread above. > "Styling is not handled by HTML. It's a separate concern assigned to CSS." Missing the point again. We know styling is not handled by HTML. The point of the thread was to tell how big of a task it is to create your own HTML based reader. If you want to create your reader like it or not you have to implement support for CSS too and that too is a mammoth spec. So our only options are: A. Go implement a new browser. B. Use something like Webkit. C. Implement a small subset of the HTML and CSS specs.
- foofie 3y ago
  > The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them. That's true for basically any non-trivial document rendering format. For example, take a look at the PDF spec. Even basic things like parsing the document format is a formidable task. HTML in comparison is a trivial format. The same goes for technologies like TeX or even Microsoft's own Word format, which Microsoft famously had lots of problems supporting. It is a hard problem for all formats, not just HTML. > The point of the thread was to tell how big of a task it is to create your own HTML based reader. You're confusing some things. A document format is one thing, but a renderer with specific capabilities is an entirely different thing. You're commenting on the document format and the styling and layout system, and now you're shifting the conversation to what it takes to implement a renderer. Debates on document formats are entirely separate and orthogonal to debates on how to implement renderers. Renderers for the most trivial things are tremendously complex. There are a myriad of good reasons why we're seeing GUI frameworks built on top of webviews in spite of all the complains about the formats that webviews support, and in spite of the myriad low-level rendering frameworks already available. To understand the poiny, try to think through the requirements list to implement a renderer for Markdown. It's a document format with a half dozen of features. Would you call it trivial?
  - mapreduce 3y ago
    > You're confusing some things. A document format is one thing, but a renderer with specific capabilities is an entirely different thing. You're commenting on the document format and the styling and layout system, and now you're shifting the conversation to what it takes to implement a renderer. If you follow the comment you replied to the discussion was about implementing a renderer. So no, I am not shifting the conversation to implement a renderer. The conversation is about implementing a renderer. That it is incredibly difficult to do today with the modern specs is the point.
- math_dandy 3y ago
  What about option D. Use a WebView. This is exactly what the author did. The point of the proposal is identify which features of a WebView can be used (and which must not) if the goal is to produce nice text layouts in multiple form factors. But the rendering of HTML and CSS, and the execution of Javascript are solved problem.
wharvle 3y ago
> Styling is not handled by HTML. It's a separate concern assigned to CSS. For convenience HTML offered default styling. It in-fact was, and to some degree still is. I assure you we achieved a hell of a lot of styling before css existed, and for some time after it did but before most of us were using it (much), using features of HTML, some of which were explicitly there to support styling.

by foofie 3y ago

mapreduce 3y ago

> "It still is." It still is but you are missing the point of the thread. HTML still is hypertext, some links, some images, some tables. No doubt about that. But HTML is also so much more than that. The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them. It's like "go implement a new browser" like someone said in this thread above. > "Styling is not handled by HTML. It's a separate concern assigned to CSS." Missing the point again. We know styling is not handled by HTML. The point of the thread was to tell how big of a task it is to create your own HTML based reader. If you want to create your reader like it or not you have to implement support for CSS too and that too is a mammoth spec. So our only options are: A. Go implement a new browser. B. Use something like Webkit. C. Implement a small subset of the HTML and CSS specs.

foofie 3y ago
> The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them. That's true for basically any non-trivial document rendering format. For example, take a look at the PDF spec. Even basic things like parsing the document format is a formidable task. HTML in comparison is a trivial format. The same goes for technologies like TeX or even Microsoft's own Word format, which Microsoft famously had lots of problems supporting. It is a hard problem for all formats, not just HTML. > The point of the thread was to tell how big of a task it is to create your own HTML based reader. You're confusing some things. A document format is one thing, but a renderer with specific capabilities is an entirely different thing. You're commenting on the document format and the styling and layout system, and now you're shifting the conversation to what it takes to implement a renderer. Debates on document formats are entirely separate and orthogonal to debates on how to implement renderers. Renderers for the most trivial things are tremendously complex. There are a myriad of good reasons why we're seeing GUI frameworks built on top of webviews in spite of all the complains about the formats that webviews support, and in spite of the myriad low-level rendering frameworks already available. To understand the poiny, try to think through the requirements list to implement a renderer for Markdown. It's a document format with a half dozen of features. Would you call it trivial?
- mapreduce 3y ago
  > You're confusing some things. A document format is one thing, but a renderer with specific capabilities is an entirely different thing. You're commenting on the document format and the styling and layout system, and now you're shifting the conversation to what it takes to implement a renderer. If you follow the comment you replied to the discussion was about implementing a renderer. So no, I am not shifting the conversation to implement a renderer. The conversation is about implementing a renderer. That it is incredibly difficult to do today with the modern specs is the point.
math_dandy 3y ago
What about option D. Use a WebView. This is exactly what the author did. The point of the proposal is identify which features of a WebView can be used (and which must not) if the goal is to produce nice text layouts in multiple form factors. But the rendering of HTML and CSS, and the execution of Javascript are solved problem.

wharvle 3y ago

> Styling is not handled by HTML. It's a separate concern assigned to CSS. For convenience HTML offered default styling. It in-fact was, and to some degree still is. I assure you we achieved a hell of a lot of styling before css existed, and for some time after it did but before most of us were using it (much), using features of HTML, some of which were explicitly there to support styling.