Tails

#2 Updated by Anonymous 2014-04-05 14:49:25

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

#4 Updated by Anonymous 2014-04-05 15:53:56

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 2014-04-05 16:20:12

> 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 Anonymous 2014-04-08 18:43:59

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 2014-04-08 19:24:12

> 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 2014-04-16 22:01:43

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]>

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.

<![endif]>

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

#9 Updated by Anonymous 2014-04-17 07:36:03

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 2014-04-21 21:21:05

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 ;-)

#12 Updated by intrigeri 2014-07-19 15:45:25

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.

#16 Updated by naar 2015-02-05 19:37:25

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

#18 Updated by BitingBird 2015-02-05 20:50:14

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

#19 Updated by naar 2015-02-07 01:20:47

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.

#21 Updated by naar 2015-02-12 17:56:18

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

#22 Updated by intrigeri 2015-02-12 18:34:57

> 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 2015-02-13 01:12:47

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 2015-02-13 08:26:07

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

#25 Updated by Anonymous 2015-02-14 17:53:12

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 2015-02-15 13:17:59

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 Anonymous 2015-02-15 16:33:51

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 Anonymous 2015-02-15 16:38:54

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 2015-02-18 09:52:44

> 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 2015-02-18 11:37:03

> 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 2015-02-18 15:26:40

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:

• http://webaim.org/
• http://www.w3.org/WAI/
• http://accessibility.umn.edu/web-accessibility.html

> 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 Feature #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:

<code class="css">
.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;
}
</code>

An other one pretty self-explanatory:

<code class="css">
.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;
}
</code>

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
  -----
  <code class="css">
  @font-face {
    font-family: "Source Sans Pro";
    src: local("SourceSansPro-Regular");
         local("SourceSansPro Regular");
         url("lib/SourceSansPro-Regular.woff");
  }
  </code>

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 2015-02-20 00:12:48

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":http://www.w3.org/TR/css3-background/#corners 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 2015-02-20 03:06:59

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 Anonymous 2015-02-20 09:18:11

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:
> # 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)?
> # replace the second one in favor of the "border-radius":http://www.w3.org/TR/css3-background/#corners 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 2015-02-20 15:45:25

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 Anonymous 2015-02-20 19:36:00

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 2015-02-21 00:40:37

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 2015-02-21 15:43:39

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

#39 Updated by naar 2015-02-22 21:29:33

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 Feature #8942. Could you link it to that one, please?

#44 Updated by intrigeri 2017-06-28 09:21:43

> * 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?

#45 Updated by intrigeri 2018-02-01 17:14:03

HTML5 would be useful for Bug #10909.