HTML5 valid Chyrp Lite

[eawmaas]

I am used to having all my websites valid html5, that's one of the reasons I installed Chyrp Lite.
But there are some errors and warnings and they can be solved quite simply and make Chyrp Light really valid HTML5 again (at least: the frontpage for now).

This overlaps with several SEO-improvements meaning that some of the improvements also result in a better SEO-score, SEO and valid-HTML are slowly moving towards each-other so I see them as one subject to be pro-active towards possibly future-issues.

Below the testresults and solutions.

I already made all changes to my production-environment and (on the front-page) there are no errors or warnings anymore.

I am adding a textfile with the issues and solutions (changes that I made), I hope it's clear enough.
html5.txt

[xenocrat]

Hello there,

Thanks for sharing this. It's been a while since I ran the pages through the W3C tester. It seems there are two warning items applicable to the Chyrp Lite base installation, and both are quite opinionated, in my opinion. ;-)

The deprecation of charset and type attributes on script tags is something that I believe has emerged from WHATWG. There is nothing inherently wrong with type="text/javascript" and therefore it's really just a stylistic opinion from WHATWG that is should be omitted.

Making UTF-8 mandatory for documents and the related deprecation of charset is also something that I believe has not always been the case throughout the era of HTML5. I prefer to keep it declared for now, to support older robots and user agents that haven't been updated and might default to Windows-1252 without the presence of the charset="UTF-8" attribute.

The requirement for all sections to have a heading is again just a WHATWG opinion asserted as a requirement. The MDN page on section discusses cases in which sections might appear without headings, and even the WHATWG spec notes it as a "general rule", i.e. not actually a requirement. A section is, according to the spec, "a thematic grouping of content, typically with a heading." (Emphasis added by me.)

I think using the section element makes much more sense within Chyrp Lite's blog articles than a div because the section is not just there for styling purposes; it is performing a semantic function, sectioning the blog article into its logical parts. I'll give some thought to the possibility of adding ARIA labels to those elements (to achieve the same effect as headlines) but I'm uncertain if that would actually be an improvement for accessibility.

[eawmaas]

Hi, thanks for your reply.

I agree on keeping section yes, the more semantics the better.

Broadly I see it this way, the W3C validator is what there is, if you hold on to that you're synchronized with a huge group of individuals, committees, organizations and companies.

Ofcourse: we can disagree, but then we need to work on changing the standards. For me it's the same as with everything: there are laws, rules, morals etc. and we may not like that or disagree but it is what is for now and we must comply first and from there work on change. This keeps chaos at a distance.

See what you do or don't do, I will on my side run it through the validator after an update and keep the 0 issues and the green bar, before it becomes a huge list, I love that green bar.

I will just pass through more when I encouter them and clustered and categorized, don't want to push you into anything here but I feel it should be communicated since Chyrp claims to be valid html5 and the validator says otherwise (and warnings just don't look nice and can potentially become errors later).

[xenocrat]

I'm happy to have the reports - thank you! The W3C validator is certainly a very useful measure, even if not perfect. Let's do this: I'll modify the JavaScript tags for the next release so you don't have to keep editing core files with each update. I disagree with the WHATWG opinion on this but I don't feel that strongly about it. The section warnings are something you can resolve once in the theme and then never have to worry about again, so I won't take any immediate action on that.

[eawmaas]

Sounds like a plan!
I will look for more issues on this once in a while and send you the report, we´ll see from there.

Nice to read that you are willing to give this some attention, I will try to serve the issues and solutions like I did, mostly making the changes then doesn't cost a lot of time.

As for the JavaScript: even Google now removed these attributes from their Gtag-code and TagManager-code, they even prefer that websitebuilders use a nonce, they have a separate GM-tag for that. Slowly the big guys are moving towards standardisation (finally) and you might expect that from Google since they are so strong about security.

Anyway: I will once in a while have a look around on this and I will try to add the subject of SEO to it, it gives Chyrp a strong clean backbone (so many are hacking their own sourcecode to make things work while the main reason is invalid html...)

Thank you!

[eawmaas]

Okay, hi again!
I have a new question on this (validation), without knowing I can't go further with several things.
As I pointed out earlier there was a validation-issue concerning a section without heading, this is <section class="body"> in all the feathers, I am taking text.twig as an example.
I have made some changes:
-I put the post_byline outside the if (not related but imo a post can have no title but every post has an author)
-I changed <h6 class="post_byline"> into <section><h3 etc., this solves the validation issue and puts headers in the right order (SEO)

Other feathers cause the same issues, they need this change too. But:
1: are you okay with this?
2: this means changing all feathers in all themes I believe? (I don't see any other way)
3: we could put post.body in a section with a header too, but imo this is not what the element is meant for, the main-post.body should be in <article and additional things should be in <sections , but if you want the post-content in a section too then that's okay for me as long as it has a heading.

Now there's another thing that I would like to add to the feathers too, it's for a module that displays the update-date (in another section with heading) when a post is updated and does nothing with posts that are original (not updated ever). Best is to put it in the feathers. I could put it in post.twig but then it's either high up or way down the page, while it belongs to the post-content, so I prefer the feathers. Again: I don't see any other way than modifying the feathers to get something into the post-content like with a trigger or so and I might want to be able to do that another time in the future again.

new html5-valid text.twig (other feathers need the same "treatment" too)

{% extends "content" ~ DIR ~ "post.twig" %}

{% block content %}
{% if post.title is not empty %}
<h2 class="post_title">
<a href="{{ post.url() }}" rel="bookmark" title="{{ 'Permanent link to &#8220;%s&#8221;' | translate | format(post.title | striptags | normalize | fix(true)) }}">{{ post.title }}</a>
</h2>
{% endif %}
<section><h3 class="post_byline">
<a href="{{ url('author/' ~ post.author.id) }}">{{ "Written by %s" | translate | format(post.author.name) }}</a>
</h3></section>
{{ post.body }}
{% endblock %}

old text.twig:

{% extends "content" ~ DIR ~ "post.twig" %}

{% block content %}
{% if post.title is not empty %}
<h2 class="post_title">
<a href="{{ post.url() }}" rel="bookmark" title="{{ 'Permanent link to &#8220;%s&#8221;' | translate | format(post.title | striptags | normalize | fix(true)) }}">{{ post.title }}</a>
</h2>
<h6 class="post_byline">
<a href="{{ url('author/' ~ post.author.id) }}">{{ "Written by %s" | translate | format(post.author.name) }}</a>
</h6>
{% endif %}
<section class="body">
{{ post.body }}
</section>
{% endblock %}

Thanks for your attention!

[xenocrat]

I'm probably going to aria-label sections within post articles that don't already have headlines - this will resolve the landmarking and make the validator happy. I'm doing a pass to look at heading hierarchy throughout the templates, but this requires some careful consideration.

Regarding your Updated module: is this something you are looking to add to your own theme? You can put this in post.twig and you don't need a module - it can all be done in Twig. Posts have an "updated" attribute which is either true or false. Just after the {% endblock %} in post.twig you can add something like:

{% block content %}{% endblock %}
{% if post.updated %}
<section>
<!-- Your updated date message -->	
</section>
{% endif %}

[eawmaas]

Thanks for the tip, I will now just wait for your changes and see in a new release what the status is.

The module I wrote adds a line on top of the text that says: Post updated: xx-xx-xxxx
It only appears when a post has been updated ofcourse, otherwise there will be nothing.

I tried post.twig but it only allows me to add this on top of the whole post which will be above the title or I can place it below or above the footer, which will make it difficult to see on first glance, I want it to stand out a bit. So I want it in the feather that shows the post-content, I don't see any other opportunity to get inside there.

As for the validation: every feather has a section without heading and a <h6 which is out of place, if you have used one of those for making a post, then the validator will throw a warning or error when looking at the frontpage because these posts are on there too, there's no way to get rid of that issue without changing the feathers to a valid standard.

I am already working with the module now, but I can not share it because it only works as I want it when the feathers that I use are changed,

This is the text.twig that I use, the module is "postupdated":

{% extends "content" ~ DIR ~ "post.twig" %}

{% block content %}
{% if post.title is not empty %}
<h2 class="post_title">
<a href="{{ post.url() }}" rel="bookmark" title="{{ 'Permanent link to &#8220;%s&#8221;' | translate | format(post.title | striptags | normalize | fix(true)) }}">{{ post.title }}</a>
</h2>
{% endif %}
<section><h3 class="post_byline">
<a href="{{ url('author/' ~ post.author.id) }}">{{ "Written by %s" | translate | format(post.author.name) }}</a>
</h3></section>
{% if (module_enabled("postupdated")) %}
{% if post.updated is not empty %}
<section class="postupdated"><h3><span class="updatedicon">&#x1F4DD;&nbsp;</span><span class="updated">{{ "Post updated:" | translate }}</span>&nbsp;&nbsp;&nbsp;{{ post.updated_at }}</h3></section>
{% endif %}
{% endif %}
{{ post.body }}
{% endblock %}

Thanks again!

[eawmaas]

Just a note on the side:

when you are working on the area-roles you might want to look to these two common issues that the validator gives on all blogposts (not frontpage):

Error: Bad value complementary for attribute role on element [article](https://html.spec.whatwg.org/multipage/#the-article-element).

[From line 1078, column 1; to line 1078, column 49](https://validator.w3.org/nu/#l1078c49)

/a></div>↩<article role="complementary" class="commentary">↩<ol i

Warning: Article lacks heading. Consider using h2-h6 elements to [add identifying headings to all articles](https://www.w3.org/wiki/HTML/Usage/Headings/Missing).

[From line 1078, column 1; to line 1078, column 49](https://validator.w3.org/nu/#l1078c49)

/a></div>↩<article role="complementary" class="commentary">↩<ol i

I have been reading about this subject a bit and the role complementary can not belong to block-elements especially <article. It should really be a complimentary block of code. The complimentary-role typically has one html-element that does the same (and even better) which is <aside
On top of that: it is better to use aside instead of role="complementary", it does the same job but is more widely recognised by screenreaders etc.

This article is very informative: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/complementary_role

[xenocrat]

I've committed a bunch of template changes that should address a lot of these issues.

[eawmaas]

Great to hear!