elinks is missing some key features (including HTML4 features) needed for graceful degradation of modern websites

inga-lovinde commented 2 days ago

I didn't find any related issues on this topic (besides https://github.com/rkd77/elinks/issues/327), so I thought I'd better document this here. Note that one of the missing features is absent from elinks (0.17.1.1) despite being present in links (2.30).

Maybe some day someone will feel like addressing some of these issues; I think that would be really helpful to enable creation of modern websites that can still be rendered and interacted with more or less correctly in elinks.

elinks renders the entire document, even the parts it should not display

CSS display: none

References: https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_none , https://www.w3.org/TR/CSS1/#display (it's a part of CSS1 standard, released in 1996).

Even though elinks has limited CSS support,

elinks displays blocks with inline style="display: none"; links (2.30) doesn't;
elinks displays blocks with classes for which global stylesheet sets "display: none";
elinks displays custom elements for which global stylesheet sets "display: none".

`hidden` attribute

References: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/hidden , https://www.w3.org/TR/2014/REC-html5-20141028/editing.html#the-hidden-attribute (it's a part of first HTML5 standard, mainstream browsers started supporting it in 2011).

Of course elinks doesn't aim (as I understand) to support HTML5, but still, hidden attribute could be an alternative for display: none, if it was supported. It might also be easier to implement (no need to compute CSS selectors, just skip the entire DOM subtree when there is hidden attribute), but I don't really know how elinks works.

`template` elements

References: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template , https://www.w3.org/TR/2014/REC-html5-20141028/scripting-1.html#the-template-element (it's a part of first HTML5 standard too, mainstream browsers only started supporting it in 2013-2014).

The problem with <template> element is that, as opposed to all the other elements added in HTML5, it does not by itself support graceful degradation. While with stuff like <article> or <header>, browsers not supporting HTML5 will just ignore these tags (but render the content) or treat them as <div>s, which would not be pretty but would still convey the basic meaning somewhat... the content of <template> should never be rendered.

Of course it's on W3C that they added this feature in such a way that the pages using it will not just degrade but will break in the old browsers unaware of it. But at least for some old browsers one can work around the breakage with display: none or hidden. It seems that there is no way to tell elinks to not render some parts of DOM tree, so there seems to be no way to use <template> (which is a significant part of Web Components API) at all if keeping compatibility with elinks is desired.

(I'm not saying that elinks should support <template> (even in the sense of not rendering its content because it does not and should not support Web Components anyway); this part is just an explanation why support for display: none might be desired and why it can not always be worked around.)

elinks handles disabled buttons as if they were not disabled

References: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/disabled , https://www.w3.org/TR/html401/interact/forms.html#adef-disabled (it's a part of HTML4 standard, released in 1999).

MDN:

The Boolean disabled attribute, when present, makes the element not mutable, focusable, or even submitted with the form. The user can neither edit nor focus on the control, nor its form control descendants.

HTML4:

When set, the disabled attribute has the following effects on an element:

Disabled controls do not receive focus.

Disabled controls are skipped in tabbing navigation.

Disabled controls cannot be successful.

[...] A successful control is "valid" for submission. Every successful control has its control name paired with its current value as part of the submitted form data set.

But elinks includes both disabled <button>s and disabled <input type="submit">s in arrow keys navigation, presents them as focusable, and submits the form on Enter when they're focused (passing button's control name paired with its value as part of the submitted form data set). A minor issue, but an issue nevertheless.

Example

This is the HTML document I used for testing:

<html>
  <head>
    <style>
      .hidden { display: none }
      custom-element { display: none }
    </style>
  </head>
  <body>
    <form>

      <p>Enabled</p>
      <p><button type="submit">button type=submit</button></p>
      <p><button>button</button></p>
      <p><input type="submit" value="input type=submit"></p>
      <p><input type="button" value="input type=button"></p>

      <p>Disabled</p>
      <p><button type="submit" disabled>button type=submit</button></p>
      <p><button disabled>button</button></p>
      <p><input type="submit" disabled value="input type=submit"></p>
      <p><input type="button" disabled value="input type=button"></p>

      <p>Hidden text</p>
      <p hidden>Paragraph with "hidden" attribute</p>
      <p style="display: none">Paragraph with display: none inline style</p>
      <p class="hidden">Paragraph with class="hidden"</p>
      <custom-element>Custom element with display: none global style</custom-element>
      <template>Template element</template>

      <p>The end</p>
    </form>
  </body>
</html>

All four "disabled" buttons are unfocusable and grayed out and cannot be clicked on to submit the form in FF and Chromium; all four buttons are focusable and can be used to submit the form in elinks (and there is no visual indication that they're disabled).

All five "hidden text" paragraphs are displayed in elinks, even though the second one (with inline style) is not displayed in links 2.30; all five are not rendered in recent FF and Chromium.

(Just in case this makes any difference, I was using elinks 0.17.1.1-r1 as packaged for Alpine, on Alpine edge.)

AntyElo commented 2 days ago

elinks is missing some key features CSS display: none

try with:

set document.css.ignore_display_none = 0

in elinks.conf

inga-lovinde commented 2 days ago

@AntyElo , oh wow, thank you, it works! (at least for <p style="display: none"> and for <p class="hidden">; doesn't work for other examples of hidden content in the HTML document above)

I wonder why is it ignored by default? The description of this option makes it seem as if "ignore_display_none" should be disabled by default... https://github.com/rkd77/elinks/blob/v0.17.1.1/src/document/css/css.c#L43L48

rkd77 commented 1 day ago

Thanks for reporting this. Could you make smaller parts, test file and one issue per test file? Now it is a few bugs in one issue. In commit above disabled inputs are not rendered as links.

rkd77 / elinks