bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Stefan Monnier]

Package: Emacs
Version: 27.0.50


When I ask `M-x eww RET https://git.sr.ht/~sircmpwn/core.sr.ht/tree RET`
I get a result where the files are listed as:

    d--------- 
    .builds/ 
    -rw-r--r-- 
    .gitignore 
    96 bytes 
    -rw-r--r-- 
    .gitmodules 
    107 bytes 
    -rw-r--r-- 
    LICENSE 
    1.4 KiB 
    -rw-r--r-- 
    README.md 
    184 bytes 
    -rwxr-xr-x 
    setup.py 
    1.4 KiB 
    d--------- 
    srht/ 
    -rwxr-xr-x 
    srht-migrate 
    113 bytes 
    -rwxr-xr-x 
    srht-update-profiles 
    708 bytes 

whereas I'd expect something more like:

    d--------- .builds/
    -rw-r--r-- .gitignore               96 bytes
    -rw-r--r-- .gitmodules             107 bytes
    -rw-r--r-- LICENSE                 1.4 KiB
    -rw-r--r-- README.md               184 bytes
    -rwxr-xr-x setup.py                1.4 KiB
    d--------- srht/
    -rwxr-xr-x srht-migrate            113 bytes
    -rwxr-xr-x srht-update-profiles    708 bytes


-- Stefan

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> When I ask `M-x eww RET https://git.sr.ht/~sircmpwn/core.sr.ht/tree RET`
> I get a result where the files are listed as:
>
>     d--------- 
>     .builds/ 

shr supports a very minimal subset of CSS, and that page is just a soup
of divs (which has block display syntax by default):

      <div class="mode">
        <span title="40000">
          
          d---------
          
        </span>
      </div>
      <div class="name tree">
        
        <a href="/~sircmpwn/core.sr.ht/tree/master/.builds"
        >
          .builds/
        </a>
        
      </div>
      <div class="commit">
        
      </div>

In addition, eww doesn't support external CSS at all, so what you're
seeing is what I'd expect.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Stefan Monnier]

>> When I ask `M-x eww RET https://git.sr.ht/~sircmpwn/core.sr.ht/tree RET`
>> I get a result where the files are listed as:
>>
>>     d---------
>>     .builds/
>
> shr supports a very minimal subset of CSS, and that page is just a soup
> of divs (which has block display syntax by default):
>
>       <div class="mode">
>         <span title="40000">
>           
>           d---------
>           
>         </span>
>       </div>
>       <div class="name tree">
>         
>         <a href="/~sircmpwn/core.sr.ht/tree/master/.builds"
>         >
>           .builds/
>         </a>
>         
>       </div>
>       <div class="commit">
>         
>       </div>

I saw that, but I'm not familiar enough with HTML to know if it could be
simplified without impacting its use in various other circumstances (in
which case we could lobby SourceHut's author).

> In addition, eww doesn't support external CSS at all, so what you're
> seeing is what I'd expect.

Any hope to see some incremental improvement that would get us closer to
rendering these kinds of pages better?


        Stefan

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I saw that, but I'm not familiar enough with HTML to know if it could be
> simplified without impacting its use in various other circumstances (in
> which case we could lobby SourceHut's author).

It's somewhat eccentric to use <div>s here instead of <span>s here,
since <span> are "inline" while <div> are "blocks" (which is why shr
breaks the line), but it's totally normal to not care: The CSS on the
web site will just override with whatever display: foo the web site
designer wants.

>> In addition, eww doesn't support external CSS at all, so what you're
>> seeing is what I'd expect.
>
> Any hope to see some incremental improvement that would get us closer to
> rendering these kinds of pages better?

Deciding to change shr to load external resources (for CSS etc) would be
a big step..

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Stefan Monnier]

>> I saw that, but I'm not familiar enough with HTML to know if it could be
>> simplified without impacting its use in various other circumstances (in
>> which case we could lobby SourceHut's author).
>
> It's somewhat eccentric to use <div>s here instead of <span>s here,
> since <span> are "inline" while <div> are "blocks" (which is why shr
> breaks the line), but it's totally normal to not care: The CSS on the
> web site will just override with whatever display: foo the web site
> designer wants.

Hmm... so we could ask the author to use `span` instead of `div` here
and we'd get a better rendering.  I'll see what he says.

>>> In addition, eww doesn't support external CSS at all, so what you're
>>> seeing is what I'd expect.
>> Any hope to see some incremental improvement that would get us closer to
>> rendering these kinds of pages better?
> Deciding to change shr to load external resources (for CSS etc) would be
> a big step..

It already loads external resources for images, tho, so I don't see why
it would be such a big change.


        Stefan

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... so we could ask the author to use `span` instead of `div` here
> and we'd get a better rendering.  I'll see what he says.

Better, but not good.  He's really just creating a table without using
<table>, I think...

> It already loads external resources for images, tho, so I don't see why
> it would be such a big change.

The CSS would have to be loaded before rendering.  Images are loaded
after the HTML has been rendered and don't really affect layout.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Stefan Monnier]

> The CSS would have to be loaded before rendering.  Images are loaded
> after the HTML has been rendered and don't really affect layout.

Well, clearly it's not exactly the same, indeed, but I thought you were
referring to the underlying privacy problem of fetching
a remote resource.


        Stefan

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Well, clearly it's not exactly the same, indeed, but I thought you were
> referring to the underlying privacy problem of fetching
> a remote resource.

No, there's no additional privacy problem.

shr will never support more than an itsy-bitsy CSS subset (due to both
speed and layout considerations), so fetching CSS externally would be a
disservice to the users.

And asking web designers to change their pages so that they'll look
better in non-CSS browser isn't really scaleable.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Stefan Monnier]

> shr will never support more than an itsy-bitsy CSS subset (due to both
> speed and layout considerations),

[ Never say never, but, yes, that sounds about right.  ]

> so fetching CSS externally would be a disservice to the users.

Not sure I understand why you think so: is it because of (1) the time wasted
fetching it or (2) the slowdown imposed by parsing it or (3) the slowdown
imposed on the rendering when the CSS is large or (4) ...?

My impression is that just (1) would rarely be a performance
problem (assuming it's just one CSS file) and that the parsing could
ditch all the irrelevant properties we don't support anyway so the
impact of (3) should be minor.  So is it (2)?

> And asking web designers to change their pages so that they'll look
> better in non-CSS browser isn't really scaleable.  :-)

So what the solution?


        Stefan

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Not sure I understand why you think so: is it because of (1) the time wasted
> fetching it or (2) the slowdown imposed by parsing it or (3) the slowdown
> imposed on the rendering when the CSS is large or (4) ...?
>
> My impression is that just (1) would rarely be a performance
> problem (assuming it's just one CSS file)

It's seldom just one CSS file, and CSS files these days are often big
auto-generated monstrosities...

> and that the parsing could ditch all the irrelevant properties we
> don't support anyway so the impact of (3) should be minor.  So is it
> (2)?

(3) is minor, while (2) could be an issue.

But my point is that since we support very little CSS, spending time
fetching something that in 99% of the cases will make no difference to
our rendering is a disservice to the users.  eww is slow enough as it
is.

>> And asking web designers to change their pages so that they'll look
>> better in non-CSS browser isn't really scaleable.  :-)
>
> So what the solution?

Accept that most complex web pages will look like crap in shr and use it
for what it's suited for.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Not sure I understand why you think so: is it because of (1) the time wasted
>> fetching it or (2) the slowdown imposed by parsing it or (3) the slowdown
>> imposed on the rendering when the CSS is large or (4) ...?
>>
>> My impression is that just (1) would rarely be a performance
>> problem (assuming it's just one CSS file)
>
> It's seldom just one CSS file, and CSS files these days are often big
> auto-generated monstrosities...
>
>> and that the parsing could ditch all the irrelevant properties we
>> don't support anyway so the impact of (3) should be minor.  So is it
>> (2)?
>
> (3) is minor, while (2) could be an issue.
>
> But my point is that since we support very little CSS, spending time
> fetching something that in 99% of the cases will make no difference to
> our rendering is a disservice to the users.  eww is slow enough as it
> is.

Would an opt-in user option not suit, assuming an initial PoC succeeds?

-- 
Basil

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Stefan Monnier]

> Would an opt-in user option not suit, assuming an initial PoC succeeds?

I was thinking a command that you can run to re-render with the remote
CSS, but that's basically the same idea.

If it gives useful results, we could go crazy and introduce some config
var indicating which remote CSS are worth downloading and which aren't.


        Stefan

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Would an opt-in user option not suit, assuming an initial PoC succeeds?
>
> I was thinking a command that you can run to re-render with the remote
> CSS, but that's basically the same idea.
>
> If it gives useful results, we could go crazy and introduce some config
> var indicating which remote CSS are worth downloading and which aren't.

That's a possibility, but like I said, shr supports such a minimal
subset of CSS that you're not going to see much, if any, difference.

And there's no way to determine what CSS files are going to contain the
stuff we support, so you'd have to fetch and parse them all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That's a possibility, but like I said, shr supports such a minimal
> subset of CSS that you're not going to see much, if any, difference.
>
> And there's no way to determine what CSS files are going to contain the
> stuff we support, so you'd have to fetch and parse them all.

Anyway, making shr being ACID compliant (or something along those lines)
is, I think, beyond the scope of a bug report -- if shr is going to
render HTML according to the CSS specs, it's a monumental project (and
is, I believe) make shr so slow that you can't use it, anyway.

So I'm closing this bug report.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34920: 27.0.50; Poor eww rendering of SourceHut file "trees"

[Noam Postavsky]

severity 34920 wishlist
quit

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But my point is that since we support very little CSS, spending time
> fetching something that in 99% of the cases will make no difference to
> our rendering is a disservice to the users.

I tried loading a version of the sourcehut page with its main.css pasted
in <style type="text/css">...</style> and I can confirm it made no
visible difference.

>>> And asking web designers to change their pages so that they'll look
>>> better in non-CSS browser isn't really scaleable.  :-)
>>
>> So what the solution?
>
> Accept that most complex web pages will look like crap in shr and use it
> for what it's suited for.  :-)

Sounds like wontfix...