Feature #7021

Review & modernize website markup and css

Added by u over 3 years ago. Updated about 2 months ago.

Status:ResolvedStart date:04/03/2014
Priority:NormalDue date:
Assignee:-% Done:

10%

Category:-
Target version:-
QA Check: Blueprint:
Feature Branch:web/7021-modernize-website Easy:No
Type of work:Website Affected tool:

Description

make the website html5 / css3 / media queries compliant while keeping the design.


Related issues

Related to Tails - Feature #7627: Restructure the website Confirmed 07/19/2013
Related to Tails - Feature #8942: Make Tails logo the new favicon Confirmed 02/22/2015
Related to Tails - Feature #13199: Consider switching to a CSS framework Confirmed 06/28/2017
Related to Tails - Bug #13200: Consider making the website better suitable on mobile and small screens by implementing media queries Confirmed 06/28/2017

History

#1 Updated by intrigeri over 3 years ago

  • Status changed from New to Confirmed

IIRC, ikiwiki has a HTML5 output mode (with plenty of conditionals in the default templates, depending on whether HTML5 mode is enabled or not). It might be that "simply" enabling this option does most of the work, without needing to fork all default templates and maintain it forever on our own.

#2 Updated by u over 3 years ago

Thanks.
Switched to HTML5 in the setup files.
451f --> [websitemodernization 575ce4d]
tested locally & worskforme.

#3 Updated by intrigeri over 3 years ago

  • % Done changed from 0 to 10
  • QA Check set to Info Needed

u wrote:

Switched to HTML5 in the setup files.
451f --> [websitemodernization 575ce4d]
tested locally & worskforme.

Great! It also works for me locally, but I've not tried the CGI version (ikiwiki -setup ikiwiki-cgi.setup --rebuild). Have you?

Also, it would be good to review the ikiwiki HTML5 templates to ensure they don't use features that are not available in all the browsers we want to support. Want to have a look? These files live in the templates directory in ikiwiki's source tree.

#4 Updated by u over 3 years ago

hey,

i will execute the required test with the cgi setup too.

i am still working on the templates and css to allow for a better layout on small screens. i also try to make a little bit more semantic sense in the page layout itself.

which browsers do need support? imho, all modern browsers are html5-capable now. IE8 is not completely, but i can add some lines to make that happen and will definietly test all modifications in the browsers before :) i think that the testing will take some time though.

#5 Updated by intrigeri over 3 years ago

which browsers do need support?

Modern browsers (and their ESR versions, when available), plus whatever IE runs on Windows XP, I think.

#6 Updated by u over 3 years ago

ikiwiki -setup ikiwiki-cgi.setup --rebuild

works too.

concerning XP support, Microsoft dropped XP support today (https://www.microsoft.com/en-us/windows/enterprise/end-of-support.aspx) so i think that we might have a website which works on IE7 using graceful degradation. (website readable, but maybe not as nice as on a modern browser). what do you think?

#7 Updated by intrigeri over 3 years ago

i think that we might have a website which works on IE7 using
graceful degradation. (website readable, but maybe not as nice as on
a modern browser). what do you think?

Suits me perfectly, as long as it is entirely usable (a lot of people
will go on using XP for a while, regardless of what we, or Microsoft,
think of it).

#8 Updated by esperal over 3 years ago

I was working locally on Tails website, making it responsive using media queries. I was trying to make it look good on a mobile device.
In the html there's too many things controlled by id="something" rather than by classes which would definitely make the css file much shorter and lighter ;)
some sort of Tails css bootstrap would be useful.

When it comes to old IE we should help the users ;)

<![if lt IE 9]>
<p style="color:red; font-size:36px;">The website you are currently viewing might not work properly on your outdated Internet Explorer. Please upgrade your Internet Explorer browser ASAP to the latest version or better install the Tor Browser.</p>
<![endif]>

Ok, jokes aside (well, not quite) ... [if IE] always did the job for older IE versions.

#9 Updated by u over 3 years ago

Hello esperal

I am already working on media queries for the Tails website. And shall convert IDs to classes soon.

I will add the old browser message asap.

Thanks for your contribution.

#10 Updated by esperal over 3 years ago

No worries, if any help will be needed give me a shout. Btw. with that old browser message, font-size:36px might be bit too big ;-)

#11 Updated by u about 3 years ago

  • Assignee deleted (u)

#12 Updated by intrigeri about 3 years ago

Anyone interested in taking over without duplicating work that was already done: I have a local copy of u's websitemodernization branch, that I could share.

#13 Updated by sajolida over 2 years ago

  • Target version set to 239

#14 Updated by sajolida over 2 years ago

  • Target version deleted (239)

#15 Updated by BitingBird over 2 years ago

  • Status changed from Confirmed to In Progress
  • QA Check deleted (Info Needed)

The info was given long ago, removing the tag

#16 Updated by naar over 2 years ago

Wouldn't that make sense to link it to #7627 as subtask?

#17 Updated by BitingBird over 2 years ago

#18 Updated by BitingBird over 2 years ago

Not sure if it's a subtask, but it's definitly related, thanks for spotting it :)

#19 Updated by naar over 2 years ago

intrigeri wrote:

Anyone interested in taking over without duplicating work that was already done: I have a local copy of u's websitemodernization branch, that I could share.

I am.

#20 Updated by intrigeri over 2 years ago

  • Feature Branch set to web/7021-modernize-website

Pushed.

#21 Updated by naar over 2 years ago

Is there any cons as for a deletion of ikiwiki's HTML 5 conditional markup?

#22 Updated by intrigeri over 2 years ago

Is there any cons as for a deletion of ikiwiki's HTML 5 conditional markup?

May you please provide an example or explain in more details what you mean?

#23 Updated by naar over 2 years ago

I was writing about those <TMPL_IF HTML5> variables (and exclusively for page.tmpl, actually). By choosing to completely switch to HTML 5, its markup will not be conditional anymore and removing these variables will clearly make that template shorter while improving its readability. However, I admit the smallest delta policy makes me unsure about that proposal...

#24 Updated by intrigeri over 2 years ago

We have #7027. I'd rather not start diverging any further from upstream without pretty good reasons.

#25 Updated by u over 2 years ago

Hi,

I stopped working on this for several reasons. One was a discussion about keeping IE6 support in the loop.
This is clearly possible, in particular if you add some JS within HTML conditional comments. But, afaik, the Tails website should not include this kind of JS. Maybe this should be verified with sajolida how far backwards compatible the website should be?

Cheers!

#26 Updated by naar over 2 years ago

Given their stats, I don't think it's worth it, but tracking HTML5 Shiv as a subtree might provide an easy way to go over that.

Also, in order to not reinvent the wheel, what are your views regarding the use of a CSS framework such as KNACSS to keep local.css as local as possible?

#27 Updated by u over 2 years ago

Concerning IE6, I completely agree with you. Then again, there is also IE7 which we might need to take care of. Afair, it does not know how to handle HTML5 tags either.

Concerning HTML5shiv, i don't think we want to include unaudited JS code.

About Knacss, I'm not often in favour of such frameworks, because they increase the size of CSS files and you need to make more HTTP requests when including one or the other stylesheet.
Then again, they provide often very handy features... But I think you should discuss this with sajolida in particular.

#28 Updated by u over 2 years ago

naar wrote:

I was writing about those <TMPL_IF HTML5> variables (and exclusively for page.tmpl, actually). By choosing to completely switch to HTML 5, its markup will not be conditional anymore and removing these variables will clearly make that template shorter while improving its readability. However, I admit the smallest delta policy makes me unsure about that proposal...

Last time i checked, as far as i remember at least, there was only an option to activate in the config file of ikiwiki in order to use HTML5: http://ikiwiki.info/tips/html5/ "There is a html5 setting that can be turned on, in your setup file. Rebuild with it set, and lots of fancy new semantic tags will be used all over the place."

#29 Updated by sajolida over 2 years ago

This is clearly possible, in particular if you add some JS within HTML conditional comments. But, afaik, the Tails website should not include this kind of JS. Maybe this should be verified with sajolida how far backwards compatible the website should be?

Some time ago we decided to try very hard not to put JS on our website
(we might if we have a very good reason, but this one is not).

I don't know much about browser compatibility with HTML5 but do we
really need HTML5 that hard? What would it bring?

#30 Updated by intrigeri over 2 years ago

Some time ago we decided to try very hard not to put JS on our website (we might if we have a very good reason, but this one is not).

IMO, the main restriction is: our Tor Browser's default homepage should work just fine with JS disabled (since that's something we've been wanting to do for a while).

#31 Updated by naar over 2 years ago

u wrote:

Last time i checked, as far as i remember at least, there was only an option to activate in the config file of ikiwiki in order to use HTML5: http://ikiwiki.info/tips/html5/ "There is a html5 setting that can be turned on, in your setup file. Rebuild with it set, and lots of fancy new semantic tags will be used all over the place."

As wrote, that proposal was only submitted to lighten the file, not to replace that setting's job. But yes, it replaces some elements, despite the fact that some rooms for improvement would remain: adding skip navigation links, determining if some div and span have better alternatives and perhaps reworking a bit the structure.

Thus, here is what index.html will be with its HTML 5 markup:

body
├── div class="banner" 
└──  article class="page" 
     ├──  section class="pageheader" 
     │    ├──  header class="header" 
     │    │    ├──  span
     │    │    │    ├──  span class="parentlinks" 
     │    │    │    │    └──  ul id="crumbs" 
     │    │    │    └──  span class="title" 
     │    │    └──  form id="searchform" 
     │    ├──  nav class="actions" 
     │    └──  nav id="otherlanguages" 
     ├──  aside class="sidebar" 
     ├──  div id="pagebody" 
     │    └──  section id="content" 
     └──  footer class="pagefooter" 
          └──  nav id="pageinfo" 

Is there anything that would prevent it to be:

body
├──  header
│    ├──  div id="skiptocontent" 
│    ├──  img alt="Tails - The Amnesic Incognito Live System" 
│    ├──  div id="actions" 
│    ├──  div id="otherlanguages" 
│    └──  div id="searchform" 
├──  nav
├──  main
│    └──  article
│         ├──  h1
│         ├──  p id="breadcrumbs" 
│         ├──  h2
│         └──  p
└──  footer
     └──  nav id="pageinfo" 

That said, I possibly lack of some elements to understand the reasons of such a structure (then comments are more than welcome), but it would be neat to see the its HTML markup being as clean as the one of some references:

Concerning IE6, I completely agree with you. Then again, there is also IE7 which we might need to take care of. Afair, it does not know how to handle HTML5 tags either.

Indeed.

Concerning HTML5shiv, i don't think we want to include unaudited JS code.

Given who worked on it, I'm quite confident in that lib' (see also this WHATWG blog entry), but JS gurus hanging around here are very welcome to (dis)confirm my mind.

Conversely, I'm wondering if the number of connections to the website with an IE 6 < IE 9 UA is high enough to justify using something else that conditional comments as suggested by esperal in #7021-8.

About Knacss, I'm not often in favour of such frameworks, because they increase the size of CSS files and you need to make more HTTP requests when including one or the other stylesheet.

  1. I'm not sure to understand what you mean. Is it about merging local.css or style.css and knacss.css?
  2. Yes, simultaneously, but I was not thinking of it as a third file...

local.css is 22836 bytes, quite heavy for the actual needs, and would deserve a little clearing. For example, removing all properties but float:right and padding:0 from the following declaration doesn't break anything:

.pageheader #otherlanguages ul {
  padding: 0px;
  /* reduce the extra vertical space between title and body
  margin-bottom: 1.385em;  13×1.385=18px
  margin-top: -0.538em;  13×1.538=20px */
  border-bottom: none;
  display:inline;
  float:right;
  position:relative;
  top:0px;
  height:35px;
}

An other one pretty self-explanatory:

.pageheader .actions li {
  display: inline;
  padding: 0.1em;
  margin:0.1em;
  display:inline;
  margin-top:1em;
  padding:4px;
  margin-right: 0.5em;
  position:relative;
  top:0.2em;
}

IMO, using KNACSS would permit to compact it to 5 Kbytes max while covering most visual terminals.

Further, if you are concerned in perf':
  • banner.png could be replaced by its (inline?) SVG alternative, cut to 550px of width or simply reduced (losslessly, of course):
    $ stat -c %s banner.png
      13472
    $ optipng -o6 !!$ && advdef -z3 !!$
    $ stat -c %s !!$
      6106
    
  • SourceSansPro-Regular.ttf could be converted to WOFF 1.0 and asked locally before sending it:
    $ stat -c %s SourceSansPro-Regular.ttf
      149972
    $ sfnt2woff !!$
    $ stat -c %s !!$:r.woff
      68708
    -----
    @font-face {
      font-family: "Source Sans Pro";
      src: local("SourceSansPro-Regular");
           local("SourceSansPro Regular");
           url("lib/SourceSansPro-Regular.woff");
    }
    

sajolida wrote:

I don't know much about browser compatibility with HTML5 but do we really need HTML5 that hard? What would it bring?

You might be interest by Future Web Accessibility: HTML5 Semantic Elements.

#32 Updated by naar over 2 years ago

Just to keep track of that, the breadcrumb trail could be reworked too.

Currently, that one includes home.jpeg and crumbs.gif as separator. Would you agree to:
  1. replace the first one with its SVG equivalent, permitting to drop its visible white background (JPEG does not support transparency) and gain in size (SVG being lighter by far and even a little more when served as gzip-compressed)?
  2. replace the second one in favor of the border-radius and background (with a linear-gradient value) CSS properties?

I've also found an interesting survey that might lead to modify the markup behind.

Otherwise, what do you think about changing the actual favicon for tchou's logo?

#33 Updated by BitingBird over 2 years ago

The logo doesn't look so good when it's so small, but it would be more logical (you can see how it would look like by opening the logo in a new tab, it becomes the favicon of the new tab :))

#34 Updated by u over 2 years ago

naar wrote:

Just to keep track of that, the breadcrumb trail could be reworked too.

Currently, that one includes home.jpeg and crumbs.gif as separator. Would you agree to:
  1. replace the first one with its SVG equivalent, permitting to drop its visible white background (JPEG does not support transparency) and gain in size (SVG being lighter by far and even a little more when served as gzip-compressed)?
  2. replace the second one in favor of the border-radius and background (with a linear-gradient value) CSS properties?

I'm in favour of this.

I've also found an interesting survey that might lead to modify the markup behind.

Otherwise, what do you think about changing the actual favicon for tchou's logo?

Completely in favour but i would use a version with a transparent background if possible.

#35 Updated by naar over 2 years ago

u wrote:

Completely in favour but i would use a version with a transparent background if possible.

Sure!

BitingBird wrote:

The logo doesn't look so good when it's so small, but it would be more logical (you can see how it would look like by opening the logo in a new tab, it becomes the favicon of the new tab :))

Perhaps we could get rid of its smiling face and draw a thin edge on the top side of the connector (from our point of view)?

I've made a quick draft (GIMP is rather complex for me... ). How do you feel it?

#36 Updated by u over 2 years ago

naar wrote:

u wrote:

Completely in favour but i would use a version with a transparent background if possible.

Sure!

BitingBird wrote:

The logo doesn't look so good when it's so small, but it would be more logical (you can see how it would look like by opening the logo in a new tab, it becomes the favicon of the new tab :))

Perhaps we could get rid of its smiling face and draw a thin edge on the top side of the connector (from our point of view)?

I've made a quick draft (GIMP is rather complex for me... ). How do you feel it?

I think it's indeed better to take the smiley face off from the favicon but only for the purpose of the favicon :) One should do that in inkscape with the original SVG though.

#37 Updated by BitingBird over 2 years ago

Yeah it's better. But maybe we should create another ticket for the favicon issue (there seems to be a consensus) and keep this one about markup/CSS ?

#38 Updated by naar over 2 years ago

Fine with me.
u, I will comment your own over there.

#39 Updated by naar over 2 years ago

BitingBird wrote:

Yeah it's better. But maybe we should create another ticket for the favicon issue (there seems to be a consensus) and keep this one about markup/CSS ?

Tracked in #8942. Could you link it to that one, please?

#40 Updated by BitingBird over 2 years ago

  • Related to Feature #8942: Make Tails logo the new favicon added

#41 Updated by u about 2 months ago

  • Related to Feature #13199: Consider switching to a CSS framework added

#42 Updated by u about 2 months ago

  • Related to Bug #13200: Consider making the website better suitable on mobile and small screens by implementing media queries added

#43 Updated by u about 2 months ago

  • Status changed from In Progress to Resolved

Status of this ticket:

  • We've switched to HTML5 some time ago.
  • We never really implemented media queries in the CSS, except for one. I'll file a dedicated ticket for that one.
  • Since then, we do use some JS on the website. We do only use vanilla JS (except in the installation assistant which uses jQuery).
  • The ticket suggested switching to a CSS framework. I think we can reconsider this once we do a redesign of the website. However, this is currently not on our roadmap. I'll file a dedicated ticket for this.
  • 2 to 3 years later I think we can finally skip old IE versions and we don't have to implement any conditional comments as suggested in #7021#note-8

Closing this messy ticket.

#44 Updated by intrigeri about 2 months ago

  • We've switched to HTML5 some time ago.

Really? ikiwiki.setup still says html5: 0, wiki/src/templates/page.tmpl has conditions that depend on this setting, and the generated HTML still looks like it has always been (e.g. we have <div class="page"> while ikiwiki would write <article class="page"> if HTML5 was enabled). The topic branch that switched to HTML5 was not merged.

So perhaps we need a new dedicated ticket about switching to HTML5?

Also available in: Atom PDF