[RC] Helion

[cabot]

Hello,

The style is the phpBB 3.3 version of Artodia: Helion.

Its release is the result of a collaboration with Mannix_, we have rethought the way we work with the code, using modern CSS properties in the same spirit as Arty.

In other words, the design is still the same, but the code has been adapted to keep pace with developments on the Web. It is compatible with all modern browsers, as well as with right-to-left languages, without overloading the properties as is currently the case with all styles (no more bidi.css).
Helion is a streamlined style with a powerful engine!

The read/unread status icons are svg files embedded in the HTML.
The two main colours (blue and red) are very easy to change: just change two values in the CSS and the whole style will be affected, including the status icons.

We've added a config.html file to the template directory to configure some basic options.

Style demo

GitHub repo

helion.png

[Gumboots]

The style itself is pleasant enough, as a basic old school default style. However, the coding behind it sounds interesting. I'll take a closer look.

I agree that bidi.css, or at least most of it, should be redundant these days. Most of it can be ditched by using flex and grid, along with start/end for things like text-align, and inline margins and padding. You may still need a couple of .rtl declarations in places, but not enough to warrant an entire file. I'm almost at the point of thinking that same could apply to responsive.css too.

Re the use of SVG: One trick I like is using an .svg as a CSS mask for an element that has a background colour defined. It allows keeping the SVG code out of the template (meaning you can swap SVG's easily) while allowing the displayed colour of the SVG to change in response to CSS changes. It's ideal (IMO) for multi-variant styles where you want icons to change colour by variant.

The config.html interests me too. I've never played with that idea, but it seems very easy to implement.

[cabot]

Well, here are all the RTL adjustments:

Code: Select all

.rtl {
	--text-shadow: -1px 1px 0 hsla(0, 0%, 0%, 0.2);
	--content-flow-start: right;
	--blockquote-icon: '\f10e';
	--rtl-scale-x: scaleX(-1);
}

[Gumboots]

Lol. Looks extravagant.

[Gumboots]

The login drop menu is not keyboard-accessible. It's also still lacking keyboard access to things like "Display and sorting options" and the "Jump to" (not that I think anyone ever uses the jumpbox).

I have a bit of a thing about a11y. Some people have enough trouble using the web without us making it more difficult. And yes, I realise you were focusing on other things in this exercise, and some of the faults are default phpBB. It's nice work overall. A few touches for extra good practice would be useful though. Once you have them, you can use them in any style.

You could add tabindex="0" to the currently non-focusable dropdown-trigger spans. That's easy to do with minimal js and will make them focusable. The catch is that even though they are now all focusable, the default dropmenu code still doesn't allow opening them via keyboard if they are triggered by a span (even though it works if the trigger is an anchor). Fixing it for span triggers would require more js shenanigans, and frankly it's probably better to change them to anchors (they really should be buttons eveywhere, but that's even more work).

Code: Select all

//	This works for focus, but still does not allow default
//	.dropdown-trigger spans to open the menu via keyboard!
//	They still require an actual click to open the menu.
	const spanTriggers = document.querySelectorAll('span.dropdown-trigger');
	for (const spanTrigger of spanTriggers) {
		spanTrigger.setAttribute('tabindex', '0');
	}

And get rid of any positive values of tabindex that you run across (coz dat be teh evilz) which you could do a similar way. Just run document.querySelectorAll('thingies.wot.have.nasty.positive.tabindex') and thump the mongrels into submission.

Code: Select all

//	This gets rid of all default phpBB positive tabindex values!
	const tabPositives = document.querySelectorAll("[tabindex]");
	for (const tabPositive of tabPositives) {
		if (tabPositive.tabIndex > 0) {
			tabPositive.setAttribute('tabindex', '0');
		}
	}

Running that one in overall_footer.html makes all the quick reply/posting editor/etc forms behave properly for keyboard access, without needing to hack the markup.

There are still a couple of template conditionals that might screw you up, but not many, and they aren't hard to find and kill...

Code: Select all

<!-- IF CAPTCHA_TEMPLATE and S_CONFIRM_CODE -->
		<!-- DEFINE $CAPTCHA_TAB_INDEX = 3 -->
		<!-- INCLUDE {CAPTCHA_TEMPLATE} -->
	<!-- ENDIF -->

[cabot]

Thanks for the feedback.

As far as the login drop-down menu is concerned, I deliberately decided that it was just a visual gimmick with no added value and I didn't want to make it accessible because the link to the login page is focusable and sufficient. But perhaps I should reconsider my position.

And as you say, prosilver doesn't really (to put it mildly) comply with accessibility criteria, but I'm not casting a stone because it was written in another era and still makes efforts in this direction if you bear in mind its age.

We should get rid of all the positives tabindex and let the focus flow in the natural order of things, especially when you are aware that template events can add elements to the page.
I wouldn't dare mention the registration page, which is an example of what not to do.
Oh, and also (especially?) get rid of the acceskey attributes that pollute the code. ^^

[Gumboots]

That's a reasonable point about the login drop. TBH I currently have a bee in my bonnet about converting all the default phpBB drops to a better system, so naturally that one caught my eye, but it's the rest that are the real issue.

Obviously you could get rid of all the access key rubbish with a similar js snippet. I've been manually removing them (and tabindex, etc) from any templates I am modifying anyway, but a js solution would be just as good for most users.

[Gumboots]

Something else I noticed (I found this on a style I am working on, but it applies here too).

If the header log in block is enabled, and someone fluffs a log in attempt, you end up on the full log in page. That means you are doubling up on some ID's in forms, specifically: #username, #password, #autologin.

The header block ID's are display: none; by default of course, but they will still cause a validation error, and can also cause odd effects with the triggering of #autologin (the hidden one can get checked, even though is not displayed, when you want to check the visible one, because it is first in the markup with that ID).

This is a drawback of the default markup (and code behind it) which was never designed to have the quick and full log in forms in the markup on the same page.

Changing the ID's in one of the forms screws up logging in, presumably because some of the back end code is specific to those ID's (I haven't dug into it). A few ways around it AFAICT.

1/ Rewrite whatever is on the back end (not an appealing prospect right now).

2/ Use a conditional to remove the header log in form from the markup when on the full log in page (with {% if S_IN_UCP ...} being the simplest option) and leaving the log in link itself, just in case.

----------------------------
ETA: Ended up doing this, because you can get there in memberlist.php too if you are a guest and you click a username. This is cool everywhere.

Code: Select all

<!-- ELSE IF not S_USER_LOGGED_IN -->
	<!-- IF not S_IN_UCP and not S_IN_MEMBERLIST -->
	<li class="listlevel1" id="nav_login">
		<form action="{S_LOGIN_ACTION}" method="post" id="login_quick" class="login_form">
			<fieldset class="fields1 quick_login">
				<div class="input-wrapper">
					<label for="username">{L_USERNAME}</label>
					<input type="text" name="username" id="username" class="inputbox" autocomplete="username">
				</div>
				<div class="input-wrapper">
					<label for="password">{L_PASSWORD}</label>
					<input type="password" name="password" id="password" class="inputbox" autocomplete="current-password">
				</div>
				<a href="{U_SEND_PASSWORD}" class="send_password">
					{L_FORGOT_PASS}
				</a>
			<!-- IF S_AUTOLOGIN_ENABLED -->
				<div class="input-wrapper">
					<label for="autologin" class="checkbox_label">{L_LOG_ME_IN}</label>
					<input type="checkbox" id="autologin" name="autologin">
				</div>
			<!-- ENDIF -->
				{# @Gumbootz: needs language string. #}
				<input type="submit" name="login" id="quick_login" value="Log in" class="button login_button">
				{S_LOGIN_REDIRECT}
				{S_FORM_TOKEN_LOGIN}
			</fieldset>
		</form>
	</li>
	<!-- ENDIF -->
	<!-- IF S_REGISTER_ENABLED and not (S_SHOW_COPPA or S_REGISTRATION) -->
	<li id="nav_register">
		<a href="{U_REGISTER}" role="menuitem" class="button register_button">
			{# @Gumbootz: needs language string. #}
			Register an account
		</a>
	</li>
	<!-- ENDIF -->
<!-- ENDIF -->

----------------------------
3/ Or you could get a bit more sophisticated, and only remove the header log in form for ./ucp.php?mode=login (which would require a little more Twig but is probably the best option). If using this the log in link would be redundant since you would already be on the relevant page, so you could remove that along with the form.

One other thing I am seriously thinking of changing is category headers. The default markup makes no sense, because you have the h1 up in the page header, and h3's down in the stats blocks, but there are no h2's on the board index at all. This will get flagged for bad a11y if you run it through a validator. And, obviously, h2's would be perfect for category headers anyway.

Having two separate ul's for one category makes little sense either, nor does a dl (eh wot?) and a .list-inner (zomg!) in the category header. I'm thinking it should be marked up like this:

Code: Select all

<ul class="topiclist forums">
	<li class="header">
		<h2>
			<a href="./viewforum.php?f=1">Community</a>
		</h2>
	</li>			
	<li class="row">

Or even just:

Code: Select all

<div class="forabg">
	<div class="inner">
		<h2>
			<a href="./viewforum.php?f=1">Community</a>
		</h2>
		<ul class="topiclist forums">		
			<li class="row">

I honestly cannot see any sane reason to have more than that for headers.