Sommaire
Initialement je devais écrire le prochain numéro de De tout, de rien, des bookmarks, du bla-bla. Ensuite, je me suis mis en tête de créer une page web statique. Et voici ce que ça a donné !
Partie 1
J'aurais aussi pu l'appeler Le html c'est surfait !
Ces derniers jours, je me suis mis à la création d'une page web. En gros, il s'agit d'une simple page, totalement statique (pas de code serveur ni de code côté client). Allez, on va quand même mettre un peu de css histoire d'avoir un peu de style, et pour que ça reste relativement sobre, pas d'images.
Logiquement j'aurais pu prendre un éditeur de texte tout simple et écrire mon css et mon html (la page est vraiment petite).
Mais non, malheureux ! Tout le monde sait bien que l'html, c'est surfait aujourd'hui !
Voici donc dans la suite comment créer une petite page web tout simple en utilisant Haml, Sass, solarized, Font Awesome, ruby, rake et git, le tout en utilisant Sublime Text 2.
Ha oui, et histoire que ce soit drôle, vous verrez que j'ai collé pleins de liens partout pour faire genre, spéciale dédicace à… euh non, allez, restons sympa ;-)
Contexte
Déjà, précisons le contexte :
- une page web tout simple, comportant en gros un peu de bla bla et une liste d'items
- lisible
- pas trop moche si possible
- très facile à mettre à jour (ce qui arrivera de temps en temps)
Ok, une page html avec un peu de css posée sur un serveur fait le boulot. Mais c'était trop simple, allons bon !
Le html c'est surfait !
Déjà, le html c'est vraiment surfait. Faut réellement être un développeur de la vieille école pour écrire du PHP^W html à la main. Franchement, qui voudrait en écrire encore aujourd'hui ?
La solution (enfin l'une) se trouve donc dans haml. haml qui est un langage de balisage léger pour écrire des templates. C'est plutôt orienté ruby et ça se lit très facilement.
L'indentation est utilisée pour gérer l'enchainement des blocs plutôt que les balises ouvrantes/fermantes (comme en python ou coffeescript, par exemple).
Si on prend l'exemple haml sur wikipedia voici ce que ça permet.
Version html :
<div id="sidebar">
<ul class="main">
<li class="active">
<a href="accueil.html">
Accueil
</a>
</li>
<li>
<a href="nouvelles.html">
Nouvelles
</a>
</li>
<li class="disabled">
<a>Membres</a>
</li>
</ul>
</div>
Version haml :
#sidebar
%ul.main
%li.active
%a{"href" => "accueil.html"}
Accueil
%li
%a{"href" => "nouvelles.html"}
Nouvelles
%li.disabled
%a Membres
Tout de suite, le gain est énorme ! Plus de syntaxe xml, plus lisible, indentation forcée, etc.
Ruby et rake, pour faire faussement compliqué
Le problème de tout ça, c'est qu'il faut maintenant transformer ceci en… html ! Ben oui, votre navigateur, il ne comprend pas le haml.
Heureusement, Ruby vole à notre secours !
Tout d'abord, il est nécessaire d'installer la gem haml :
gem install haml
Vous pouvez donc ensuite compiler votre fichier haml (index.haml) en fichier html (index.html) :
require 'haml'
haml = IO.read("index.haml")
hamlengine = Haml::Engine.new(haml)
html = hamlengine.render()
File.open("index.html", "w") { |f| f.write(html) }
Si vous appelez ce fichier compile.rb
, il vous suffit d'exécuter la commande ruby compile.rb
pour générer votre fichier html.
Facile, non !
Par contre, arrêtons de voir les choses en petit ! Un tel script n'est pas suffisant, il faut se dépasser un peu quand même !
Ce script va donc être placé dans un fichier Rakefile. Voici donc le contenu de ce fichier :
require 'haml'
task :default => :build
desc 'Build site'
task :build do
haml = IO.read("index.haml")
hamlengine = Haml::Engine.new(haml)
html = hamlengine.render()
File.open("_site/index.html", "w") { |f| f.write(html) }
end
Vous saisissez la différence ? Non ? Ben, pourtant elle est évidente, il suffit désormais d'exécuter la commande rake
au lieu de ruby compile.rb
!
Et si on coloriait un peu ?
Maintenant que la partie html est réalisée, passons un peu à la mise en style.
Précédemment, on utilisait essentiellement du css. Tout comme le html qui est désormais surfait, le css est également aujourd'hui une technologie quasi obsolète.
Heureusement pour nous, des petits gars bien malins nous ont concoqueté concocté Sass. Si vous avez compris ce qu'était haml par rapport à html, dites simplement qu'il en est de même à propos de Sass par rapport à css.
Sass est donc un pré-processeur css, vous permettant de l'écrire plus mieux, en enlargeant votre productivité. Il y a plein de possibilités bien sympa, comme les mixins, les nested rules et plein d'autres choses.
Lorsque vous écriviez précédemment, en css :
ul {
color: red;
}
ul li {
margin-left: 1em;
}
ul li.green {
color: green;
}
ul li a {
text-decoration: underline;
}
ul li a:hover {
font-weight: bold;
}
Vous pouvez désormais écrire en Sass :
ul
color: red
li
margin-left: 1em
&.green
color: green
a
text-decoration: underline
&:hover
font-weight: bold
Impressionnant, non !
Évidemment, pour pouvoir tout de même générer le css correspondant (car, pour rappel, ton navigateur, il ne comprend pas Sass), on va encore utiliser Ruby et la gem dédiée :
gem install sass
Voici donc un petit script pour transformer notre Sass (css/style.sass
) en css (style.css
) :
require 'sass'
sassengine = Sass::Engine.for_file("css/style.sass", :syntax => :sass, :style => :compressed)
css = sassengine.render()
File.open("style.css", "w") { |f| f.write(css) }
Mais comme on est des gens bien, on va surtout le rajouter au Rakefile précédemment créé afin qu'il ressemble à :
require 'sass'
require 'haml'
task :default => :build
desc 'Build site'
task :build do
sassengine = Sass::Engine.for_file("css/style.sass", :syntax => :sass, :style => :compressed)
css = sassengine.render()
File.open("style.css", "w") { |f| f.write(css) }
haml = IO.read("index.haml")
hamlengine = Haml::Engine.new(haml)
html = hamlengine.render()
File.open("_site/index.html", "w") { |f| f.write(html) }
end
Et voilà ! Un simple appel à rake
nous permet donc d'obtenir notre html et notre css !
On devait pas parler de couleurs ?
Ah si !
Puisqu'on y est, on ne va pas utiliser la feuille de style standard, say trop pour les loosers !
Tout d'abord, histoire que tout le monde ait la même trogne, on va commencer par utiliser la feuille de reset normalize.css. C'est une bonne alternative à beaucoup de feuilles de reset qu'on trouve habituellement et elle fait bien son boulot.
Ensuite, ben c'est simple, on va surtout utiliser les couleurs provenant de solarized. Il s'agit d'un ensemble de couleurs, plutôt bien homogènes, cohérentes entre elles et agréables à l'oeil. Parfait quoi !
Histoire de mettre aussi un peu de fun dans l'histoire, ajoutons quelques icônes. Mais comme on fait les choses biens, point d'image ! C'est trop surfait les images aussi ! Donc direction Font Awesome. Il s'agit d'une police de caractère orientée icônes. L'avantage est que c'est plutôt léger, vectoriel, coloriable facilement, propre, bien intégré à Twitter bootstrap, mais également utilisable sans. C'est propre, c'est net, c'est facile, que demander d'autre ?
Voici d'ailleurs le code Sass que j'ai utilisé pour ajouter mes quelques icônes dans ma page :
$fontAwesomePath: "font/fontawesome-webfont" !default
@font-face
font-family: "FontAwesome"
src: url("#{$fontAwesomePath}.eot")
src: url("#{$fontAwesomePath}.eot") format('eot'), url("#{$fontAwesomePath}.woff") format('woff'), url("#{$fontAwesomePath}.ttf") format('truetype'), url("#{$fontAwesomePath}.svg#FontAwesomeRegular") format('svg')
font-weight: normal
font-style: normal
font-family: FontAwesome
font-weight: normal
font-style: normal
display: inline-block
text-decoration: inherit
.icon-check-empty:before
content: "\f096"
.icon-check:before
content: "\f046"
.icon-envelope-alt:before
content: "\f0e0"
.icon-phone:before
content: "\f095"
.icon-comments-alt:before
content: "\f0e6"
.icon-comments:before
content: "\f086"
On pousse le style un poil plus loin ?
Histoire d'aller un tout petit peu plus loin, j'ai utilisé deux autres web fonts pour améliorer un peu la typographie. C'est pas grand chose, mais ça fait tout de suite la différence. C'est propre, léger, et agréable visuellement, alors pourquoi s'en priver ?
J'ai donc utilisé Numans, comme police de base et Josefin Sans pour les titres. C'est pas grand chose, mais le gain est réellement intéressant.
Voici le Sass correspondant :
@import url("//fonts.googleapis.com/css?family=Josefin+Sans:700")
@import url("//fonts.googleapis.com/css?family=Numans")
html, body
font-family: "Numans", arial, helvetica, sans-serif
h1, h2, h3, h4, h5, h6
font-family: "Josefin Sans", arial, helvetica, sans-serif
Modification et mise en ligne
Ah oui, l'objectif initial était également de pouvoir être facilement modifié et mis en ligne.
Pour la publication, c'est facile. J'ai simplement mis une règle deploy
dans mon Rakefile qui effectue un rsync vers mon serveur web. Comme c'est du statique, je n'ai rien d'autre à faire, rien a redémarrer. La modification est donc instantanément en ligne.
Mon Rakefile a donc la tête suivante. Il faut tout de même prendre en compte que, pour simplifier les choses, je génère mon contenu dans un répertoire _site
qui me permet de le pousser sans me soucier des fichiers sources.
require 'sass'
require 'haml'
task :default => :build
desc 'Build site'
task :build do
sh 'mkdir _site'
sh 'rm -rf _site/*'
sassengine = Sass::Engine.for_file("css/application.sass", :syntax => :sass, :style => :compressed)
css = sassengine.render()
File.open("_site/application.css", "w") { |f| f.write(css) }
haml = IO.read("index.haml")
hamlengine = Haml::Engine.new(haml)
html = hamlengine.render()
File.open("_site/index.html", "w") { |f| f.write(html) }
sh 'cp -R font _site'
end
desc 'Build and deploy'
task :deploy => :build do
sh 'rsync --checksum -rtzh --progress --delete _site/ www:/var/www/plop'
end
Et voilà ! rake
me compile mon projet, je peux aller le voir directement dans _site
ou utiliser serve. rake deploy
, quant à lui, me génère le contenu et le pousse sur mon serveur web.
Il ne manquerait pas un truc ?
Et si, il manque une dernière brique : git. En effet, tout le contenu source (donc _site
omis) est versionné en utilisant git. Je n'utilise pas de serveur type github ou autre, j'ai juste créé un dépôt sur mon propre serveur de fichier. Je pousse alors via ssh, c'est très largement suffisant et je n'ai pas besoin de plus de droits, je suis le seul à bosser dessus. L'avantage est qu'un dépôt git se monte en un rien de temps et qu'une connexion classique suffit à le récupérer. Je peux alors rapatrier les sources sur une autre machine qui contient Ruby et les gem nécessaires et je peux alors le modifier, générer et pousser vers mon serveur !
Et voilà !
Et, voui, et voilà !
Ok, certains diront que c'est utiliser un bulldozer pour écraser une mouche et ils n'auront probablement pas tort. Quoi qu'il en soit, cela apporte une réelle plus-value en terme de confort. Et surtout, c'est une base réutilisable de nombreuses fois, extensible (il suffit par exemple de rajouter une entrée pour compiler du coffeescript et ajouter un peu de dynamisme dans les pages, etc.).
Aparté
'tain mais je sais pas comment il fait, c'est mega super lourd de placer autant de liens dans un post !
Aparté n°2
Oui, l'écriture de ce billet est probablement plus longue que l'écriture de la dite page oueb en html+css !
Partie 2
Il faut croire que l'épisode précédent vous a intéressé (mon petit doigt me dit qu'il est même passé sur un incubateur d'excellence aux dires des mytiloïdes qui s'y trouvent). Voici donc la suite, tant attendue.
Comment ça une suite ?
Ben vous croyez quoi ?! On fait de la page oueb monsieur ! C'est un sujet sérieux ! Pas question de s'arrêter avec juste un peu de Haml, Sass, Ruby, Rake et git. Cela suffirait à des développeurs inexpérimentés, pas pour des vrais bons comme nous !
Introduction
Et il va nous sortir quoi de son chapeau ce bon monsieur ? Le problème il était de faire une page internet^W oueb statique hein !
Que des choses indispensables pour briller en société ! En l’occurrence, l'utilisation de bundler et guard et, histoire d'aller un peu plus loin, un peu de coffeescript parce qu'on le mérite bien.
Bendleure
Comme vous avez pu le remarquer, la génération de votre page html nécessitait l'utilisation de plusieurs gem ruby en l'occurrence :
Il était donc nécessaire de réaliser deux actions manuelles pour les installer. Mais les commandes c'est surfait, tout le monde le sait !
Heureusement bundler est là pour nous ! Tout d'abord, étant donné que c'est également une gem, il faut l'installer :
gem install bundler
Ha oui, je vous vois venir !
Oué mais l'autre il nous dit qu'on va supprimer l'installation manuelle des gem et il ne trouve rien de mieux à faire que d'installer une nouvelle gem !
Et là de répondre :
C'est pas faux
D'ailleurs, vous allez même créer un nouveau fichier, Gemfile
qui contiendra le code suivant :
source 'https://rubygems.org'
gem 'haml'
gem 'sass'
Vous pouvez désormais installer ces deux gem via la commande :
bundle
C'est 'achement plus facile, non ?
Cette commande va vous installer les deux gem si vous ne les aviez pas déjà et va créer un fichier Gemfile.lock
qui contient les installations réalisées et leur version. Si un tel fichier n'existe pas, bundler va essayer de récupérer la dernière version des gem. Si un fichier lock existe déjà, il va essayer d'installer la version spécifiée dans le fichier. L'avantage est que, si vous partagez ce fichier entre vos différents environnements (par exemple en le versionnant dans votre git), il vous assure d'avoir les mêmes dépendances partout. Et ça c'est bien !
Développer votre page statique est donc d'autant plus aisé qu'il vous suffit de faire un clone de votre git et d'exécuter bundler (de toute façon, qui n'a pas bundler sur sa machine aujourd'hui ?).
Moins j'en fait, mieux je me porte !
Étant donné que vous êtes une vraie feignasse, vous n'avez surtout pas envie de devoir relancer rake à chaque modification réalisée (car le temps gagné pourra être passé à moulerW faire sa veille technologique).
La première chose est donc d'ajouter guard à votre Gemfile
(vous voyez que finalement ça sert à quelque chose bundler) et l'installer via bundle
.
gem 'guard'
La deuxième chose est d'initialiser guard. Une bonne pratique est de toujours utiliser bundler pour exécuter guard. Vous n'allez donc pas exécuter guard init
mais :
bundle exec guard init
Ceci va vous créer un fichier Guardfile
qui va bien (mais qui ne fait rien).
Je vous conseille d'aller voir la documentation de guard car un certain nombre d'usages classiques sont déjà pris en charge et leur mise en œuvre est vraiment simple.
Dans notre cas, on utilise rake pour construire notre page statique. Tout naturellement, nous allons donc nous tourner vers le greffon guard-rake.
Dans le Gemfile
rajouter :
gem 'guard-rake'
et exécuter bundle
.
Ensuite, initialiser le Guardfile
avec guard-rake :
bundle exec guard init rake
Vous devez donc avoir un fichier Guardfile
qui contient :
guard 'rake', :task => 'build' do
watch(%r{^my_file.rb})
end
J'espère que vous avez déjà compris ce que ça voulait dire : lorsque le/les fichiers surveillés par watch
seront modifiés, rake sera exécuté avec la cible build
. Parfait, c'est exactement ce qu'on cherche à faire !
Il ne reste donc plus qu'à modifier un peu le watch
pour que ça corresponde à notre cas :
guard 'rake', :task => 'build' do
watch %r{^index.haml$}
watch %r{^css/(.+)\.sass$}
end
De cette manière, dès que index.haml
ou l'un des fichiers sass va être modifié, rake va être exécuté.
Faisons un petit test. Tout d'abord il convient de lancer guard :
bundle exec guard
Et voilà !
À chaque fois que vous modifierez un des fichiers surveillés, la sortie sera régénérée ! Le gain en terme de confort est loin d'être négligeable, c'est vraiment un plus pour développer correctement une page oueb statique !
L'inter a ctivité
Comme on n'est pas des mickeys, on va faire les choses en grand : on va rajouter un peu d'interactivité et de fun dans cette page tristounette !
Pour ce faire, on va rajouter un peu de code côté client. Mais bon, tout le monde le sait, le javascript c'est has been. On va donc le faire en coffeescript !
Tout d'abord, créer un répertoire js
(oui, js, pas coffee) et dedans un fichier mickey.coffee
.
Dans ce fichier, écrire le contenu suivant :
init = ->
img = document.createElement 'img'
img.src = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAUCAYAAADskT9PAAAG2UlEQVQYGXXBa2yddR3A8e/v/1zOc87pOT1tt65rx1gdEGhGGZMNZMCWrWgGqDhDAl6ShQGKIWqEvjDxRWN4ob7DqAmJCWB4wdjUsMI2YXI1yMgubKO7dKW7tWdd6drT9tyf5/n/LG0iavDzEb5AXx+mrw8LXLv62o5DnvEy1j9nxWBUAQEUUECYJwoICwTUYk39ahPZuHbkzMitwFFVRATlPwj/37W9D2148akH71zn+6pRsUUED0RBAREQDzQEBWsM2AiDAAaVCCc9oXEk8szO9489/ae/PwSceACcncyLmSP8NweIgcZVnW0H33zm0WsWL00pM63C8QehlAInAjWgMdSr4CdBgNiC74ONIHYgUYab/gxNeVsYr5otvc+PfDBwfh1wiQUGUMMXM454Gc9VmG2z9QNbiUZ8whKEMy5h2RBOhNT37CcuQDTrcnbXS5wbHMZWXKKyEE6lCT/cCoUOdV3FFS8N1IAVQDdgATUsMIDDv61QDS7Wo0oOPn4QmcogB3djapOYAIxYTNrHbNyMk3Q5W/qE79rf8MhHD3N28iyuD6JV7GwaPtoqYXExGgzVgdVrVne/3d3d/X57e/vNzHEBASwLHOblEIMx6kE5ABe4ZRMkMhAzx6COwc1kKRYr/PrIr9iw9X6S4vGLg7+kd3I7a8qC27UebNokTIJandY1a+967Vtf35ywijz/3HOvAWsNoEAj0AxY5o27zFFRcGIwQDYHjgPKHIVqFSKINaakRTwj5Bqa6Fzbzm8nn+VkY5JzhREujA8zlL/E8hW3y3333B1kMhkrIrielwFcF0i2trbucV23M8hmNw6fOjUIXy5DXoU5KqBAZMEY5tXq6JG34ZYefC+JFzlENqYe1WlJNuOv83l4fy+1UgEbx+Sac/T0bCEIAlurh1hrKZfLNaDsJpPJ17dt23Z7EAS88MILrwMPQH/BxiSU/1EuQSIFro90r0d9lyuFMUzGxXVcrCqz09M0NDRw7z0bUVVAQA2OY5ienjbZxkbrOA4dHR3+6OjocjeKoqzneWSz2XpHR8fV2Ojt2VoyQoYycWxBrYNjwEbosfeRm9ajyRRuJkNhcpzed37C8i0ryHoNGEfo7u5m8PQgjnHxfI/PiAAirFy5ksHBQeM5TvyNe+/LlIrFP5owDDft3bv30MzMjN/T06OPPvbD1A8e+U62sfEqUWuZV4vAOMjqO8ELmFeqYN98hcsjBzCJgLKNIQi4oauLgRMDzBRnQKBaq3JpbIxEIkFXVxcfDwwwVakoqYDI2pwBrhw+fPj7O3bsyPf390scxySTSVRD1LgQVtB39kClBKkAjGFeMom56x6ybd1orcoyL0FiqsBPn3iC0XyeVDLFZ+r1OkePHmV8fJynenvJnztPZyolzbWQhEjFZcHJ06dP3w40GuHZ6aKuSvtjgQEXk0Ru2wipDMSAKlouQaoBGpoYCifZ4Bq2RUpNHGobNjBSrZJKJrGqxHHM5s2bcY3hmq4urstkeRRHLbDPOBnDAgOcB44dOnxk09DgR9drzGVjLARxLNksRDUQIK7BgX1QKeI6hp4lt1IoFZlxlKLjII7LG2+9RX50lHw+z+7d/UxMTHDp0iVe6u+nHkUUfU8uT08Tx/FJhwUKOIAH1ICOpbnl27d/87p00D5BdKFd2PseungpGqShpZPYTZNwXe5YtJE33tvPvuZZRpqaqGOZyOc5deokl8fGcBzDxYsjDJ89q0uy2WjF9dfzbnHWeXLHS0c/HDrzbeFzAuiyJv/GKNOxP10vtL7xzPa4s7PFYWopHL4TtA0SxoID1gIWjM/ElUF+PvCUydywipSXIgzrWGsVETEiGFEcY/B9n2q1you7dh27eObMFiAvLBBAgcXr1q3729e+evfNu17dF3U3he4fnryfILCEtWZcwQrWCApiUBRVwfd8Rq+M8PSLbzFeqJDJpC0YA2rr9dBcmIriqWLlgqCVKIrOzw4PP/wpjPX19RkBDGCBhlwu9+bjjz++trW1VT/9dEJ27NxZXZas+i2L2o2VaarVAmq1ZIxYi4pBVNWixBKY1lQkvlFVKsUC1sYVG0fJ5iXLWdn9FXb99ZXTF86f2wiMsUAAdfmcsdYuU1UmJyflwAf/PPHJmcG+T9xFv3/ssVsWe26C517ec7w8dvJ7wBTgsyAE0uC8+sSPH/qSMYa/vLr3w5Ghkz+jsfV3P9p02+og3YAR2gDLAg8ImSOAASyQBQ61tbVd4zjO9Ojo6I3AzJKW3LmWxa05I1JpTjvr3z144ghfYOmipoFs86IukBnfRHccPzV8fNWqlVeFNfOPYrm0fHQ0fxlYA+QBB4iZ8y9jpxK3XmSVNQAAAABJRU5ErkJggg=="
img.style.position = 'absolute'
img.style.top = '-1000px'
img.style.left = '-1000px'
document.body.appendChild img
window.onmousemove = (e) ->
img.style.left = "#{e.clientX + 10}px"
img.style.top = "#{e.clientY + 10}px"
init()
Bon, c'est bien joli mais comment on l'intègre ?
Déjà, on va rajouter la gem qui va bien à bundler :
gem 'coffee-script'
Puis l'installer :
bundle
Ensuite, il faut compiler le tout en javascript. Dans le fichier Rakefile
ajouter en tête :
require 'coffee-script'
Et ajouter à la tâche :build
:
js = CoffeeScript.compile File.read("js/mickey.coffee")
File.open("_site/mickey.js", "w") { |f| f.write(js) }
Enfin, appeler le script dans la page web. Pour ce faire, ajouter une balise script pointant vers mickey.js
à la fin du fichier :
%script(src="mickey.js")
Il reste une dernière petite chose à faire, l'ajouter au Guardfile
:
watch %r{^js/mickey\.coffee$}
Désormais c'est fait ! Vous avez donc une super animation de haute voltige sur votre page web statique !
Conclusion
It's time to kick ass and chew bubble gum, and I'm all outta gum !
Et voilà, tout roule. Vous avez enfin une page web statique de très haut niveau. À ce stade vous pouvez travailler parmi les meilleurs et vous avez désormais une justification pour le prix de vos œuvres d'art.
Autre conclusion
Et sinon, ben vous aurez juste eu l'occasion de découvrir certaines technologies plutôt cool au travers d'une réalisation totalement inutile ;)
Les sources utilisées sont disponibles sur un dépôt github et le résultat tant attendu est visible
# conclusion
Posté par CrEv (site web personnel) . Évalué à 9.
Arg, la conclusion n'est pas passée…
Et voilà, tout roule. Vous avez enfin une page web statique de très haut niveau. A ce stade vous pouvez travailler parmis les meilleurs et vous avez désormais une justification pour le prix de vos oeuvres d'art.
[^] # Re: conclusion
Posté par oinkoink_daotter . Évalué à 4. Dernière modification le 07 décembre 2012 à 13:13.
Elle est bugguée ta page ! Le nyan cat se déplace avec la page quand on use de la roulette alors qu'il devrait rester collé au pointeur de souris !
Tout ça pour ça ;-)
D'ailleurs il manque un bugtracker pour ta page !
[^] # Re: conclusion
Posté par CrEv (site web personnel) . Évalué à 10.
Il y a celui de github :)
Et d'ailleurs, tout projet conséquent (comme celui-ci) se doit d'avoir des bugs. Il n'y a que ceux qui ne codent pas qui ne font pas de bug, d'où la présence obligatoire de bugs pour pouvoir justifier la complexité du développement.
[^] # Re: conclusion
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 07 décembre 2012 à 22:30.
des bugs ? certains parlent sans vergogne de fonctionnalités (bon easter egg serait déjà plus joueur :D).
Sinon, pour tes derniers liens initialement non affichés en conclusion, c'est parce que tu utilises la syntaxe
[texte avec une phôte d'ortho corrigée ensuite][]
, alors que dans Aide-Edition, il est recommandé d'utiliser une référence de la forme[texte à propos de LinuxFr][ref_linuxfr]
(un peu comme dans les revues scientifique, La Recherche ou GLMF ou autre thèse ayant sa biblio gérée dans BibTex ou pas…).Tu as, en effet, à relecture corrigé ton texte, mais pas les liens ; tu aurais utilisé des références, elles seraient sans doute restées invariantes (même après traduction, par exemple, ou, tout simplement correction d'accord / ortho). Bon, pour la peine, j'ai fait une passe sur l'intégralité du texte (hormis au moins un mot, que j'ai laissé
apparent:D).[^] # Re: conclusion
Posté par CrEv (site web personnel) . Évalué à 2.
Pour les liens, étrangement là où j'avais saisis le texte (pas sur linuxfr) ils passaient.
D'ailleurs pour nombre d'entre eux (surtout dans la deuxième partie) j'ai utilisé une référence ou en tout cas quelque chose de plus simple (pas d'accent, etc).
Merci pour les corrections ;)
[^] # Re: conclusion
Posté par BAud (site web personnel) . Évalué à 2.
oui, mais entretemps tu as modifié le texte (accord pluriel, ortho…), mais pas en cohérence pour le lien. D'où mon avis, qu'en terme de bonne de bonne pratique mieux vaut utiliser une référence, ça résiste à la modif' du texte, que ce soit pour l'ortho ou la traduction (par exemple).
[^] # Re: conclusion
Posté par lendemain . Évalué à 2.
Pourquoi ne pas utilisé la propriété "cursor"?
[^] # Re: conclusion
Posté par CrEv (site web personnel) . Évalué à 4.
Grâce à ce magnifique, ce somptueux, ce superbe outil qui vous ferait presque oublier les reliques telles cvs, rcs ou bzr, j'ai nommé Gui Teube, le nyan cat est désormais calé avec le scroll de la page !
Evidemment, sans Gui Teube, une telle correction n'aurait pas été possible. Je tiens donc à remercier bitte qui à peur de ne pas avoir rendu publique son engin, ce qui a permis l'émergence de Gui.
[^] # Re: conclusion
Posté par oinkoink_daotter . Évalué à 1. Dernière modification le 07 décembre 2012 à 16:25.
Nein ! Le scrolling à la roulette entraîne toujours un offset constant du chat par rapport à la souris. Normalement, le kitty devrait se jeter sur la souris. Ou alors, c'est un kitty frelaté.
[^] # Re: conclusion
Posté par CrEv (site web personnel) . Évalué à -5.
Mouai, je vais voir pour les renards, pour ceux qui ont un vrai navigateur internet ça doit déjà fonctionner.
[^] # Re: conclusion
Posté par CrEv (site web personnel) . Évalué à 3.
C'est bon, corrigé
[^] # Re: conclusion
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
Heuh sous Firefox (17), j'ai toujours le même soucis du chat qui bouge pas quand je scroll vertical.
# J'ai décroché là
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 10.
"Tout de suite, le gain est énorme ! Plus de syntaxe xml …"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'ai décroché là
Posté par CrEv (site web personnel) . Évalué à 3.
heu…
oué, c'est pas faux
par contre, entre écrire du xml + xslt pour ne pas écrire du html et écrire du haml le choix est très très rapidement fait. Et xslt quand tu veux faire des trucs un peu tordus, ben tu peux souvent simplement pas
[^] # Re: J'ai décroché là
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 6.
Pour écrire du statique dans son coin pourquoi pas, mais pour du dynamique qui sert vraiment à travailler ?
L'intérêt d'une couche d'accès aux données qui sort en XML, c'est l'interopérabilitude du bouzin. Par exemple, si j'ai une base de données de mes fournisseurs qui sait me sortir des fiches fournisseurs en XML, j'ai la même API d'accès à mes données pour les présenter, les exporter ou les échanger avec une appli tierce. Et en prime, je peux publier mes schémas XSD pour valider mon set de données.
[^] # Re: J'ai décroché là
Posté par Gabin II . Évalué à 3. Dernière modification le 07 décembre 2012 à 17:37.
Un petit rappel de Jean-Pierre Troll
ki fé du bien! :)
[^] # Re: J'ai décroché là
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Je suis en grande partie d'accord avec JPT. XML permet de faire beaucoup de choses, mais ce n'est pas une raison pour en mettre à toutes le sauces.
[^] # Re: J'ai décroché là
Posté par elloco (site web personnel) . Évalué à 2.
Les sites sur lesquels je travaille sont complètement faits en XML + XSLT et pourtant j'arrive à faire tout ce que je veux.
[^] # Re: J'ai décroché là
Posté par CrEv (site web personnel) . Évalué à 2.
Ha, ben moi c'était loin d'être le cas, ou alors vraiment pas simplement.
Truc tout bête, mais manipuler du texte (par exemple remplacer un caractère par un autre) est une opération tellement simpliste en xslt… ça mériterait d'envoyer les devs d'xslt faire quelques mois de stage intensif PHP + C++ MFC qu'ils apprennent réellement la programmation !
[^] # Re: J'ai décroché là
Posté par reno . Évalué à 4.
Moi quand je lis "A ce propos, XML n'est plus trop hype, mais marche plutôt bien" et plus loin "xslt", je sors le
bazookal'arme nucléaire.xslt est une abomination, point.
[^] # Re: J'ai décroché là
Posté par jigso . Évalué à 4.
xslt, c'est surfait.
[^] # Re: J'ai décroché là
Posté par CrEv (site web personnel) . Évalué à 3.
wat iz se pro blaime ?
J'aurais ptetre du écrire "Tout de suite, le gain est énorme ! Aux oubliettes la syntaxe xml"
Mais allez, courage, va jusqu'au bout :)
# c'est utiliser un bulldozer pour écraser une mouche
Posté par chimrod (site web personnel) . Évalué à 7.
J'ai peut être tort, mais je n'ai sûrement pas tord …
[^] # Re: c'est utiliser un bulldozer pour écraser une mouche
Posté par BAud (site web personnel) . Évalué à 2.
merci d'avoir attendu le 3e fil de discussion :) (je milite pour le 5e mais bon :D) ; tout cela et le reste est corrigé maintenant, hein.
# Sans javascript
Posté par François (site web personnel) . Évalué à 4.
C'est pas très beau sans javascript. C'est dommage.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sans javascript
Posté par Kekun (site web personnel, Mastodon) . Évalué à 3.
Faudrait que ça soit un navigateur Web déjà.
Parce que de ce que j'en entend dire, il s'approche plus d'un navigateur de pseudo web fait juste pour lui.
[^] # Re: Sans javascript
Posté par CrEv (site web personnel) . Évalué à 2.
Quel est le problème sous IE8 ? (vrai question, j'en ai pas sous la main) car je vois pas bien ce qui pose problème. Le css reste plutôt basique, et le js ridicule (surtout non pénalisant s'il ne fonctionne pas)
[^] # Re: Sans javascript
Posté par CrEv (site web personnel) . Évalué à 2.
?
La seule chose que tu ne vois pas sans javascript c'est la petite animation derrière le curseur. Le reste n'utilise pas de js, donc c'est juste comme partout.
Ou alors j'ai pas bien compris…
[^] # Re: Sans javascript
Posté par François (site web personnel) . Évalué à 4.
Pour être plus exact, j'utilise noscript. Et voici ce que je vois sans javascript
et avec
Après j'y connais rien…
[^] # Re: Sans javascript
Posté par CrEv (site web personnel) . Évalué à 4.
Ok, je vois.
En fait ça n'a rien à avoir avec javascript.
Les icones que tu vois sont en fait des caractères placées dans une autre police. Comme dit dans le bla bla, ça permet d'avoir quelque chose d'assez léger, facilement intégrable dans du texte, on peut utiliser css dessus, c'est vectoriel, etc.
Et je pense que ton noscript interdit le chargement des polices externes (on le voit aussi par le changement des polices sur le texte en lui-même).
Donc lorsqu'on essai d'afficher une icone, on saisi un caractère en indiquant son unicode. Et comme tu l'affiches avec une police de base, du a un caractère à la con qui apparaît car la police ne le contient pas.
Voilou
[^] # Re: Sans javascript
Posté par François (site web personnel) . Évalué à 2.
Ha ba oui, c'est ça. Noscript bloque "@font-face" par défaut.
Merci !
[^] # Re: Sans javascript
Posté par Octabrain . Évalué à 10.
Parce que t'as utilisé la "zone privée" d'unicode, et pour quoi faire ? Pour des pictos "email", "téléphone", "puce" ? Unicode dispose déjà de ces caractères. Si tu les avais utilisé, ça s'afficherait correctement avec n'importe quelle fonte, et même dans un terminal X. Là, tu utilises une "zone privée" qui ne marche donc correctement qu'avec une seule fonte (et au revoir les terminaux), c'est pas accessible ni "interopérable".
[^] # Re: Sans javascript
Posté par CrEv (site web personnel) . Évalué à 3.
mouai…
sauf que cette police a beaucoup plus que juste 4 pauv icones
mais aussi que toutes les polices n'ont pas les icones genre email, puce, etc
mais aussi que je peux vouloir une police différente
en quoi n'est-ce pas accessible ? C'est purement visuel, ça n'a pas d'intérêt autre que du style
d'ailleurs c'est pour ça que c'est uniquement du css
Tu peux le désactiver tu ne perd pas d'informations.
Si on regarde la partie adresse ou numéro de téléphone elle est au contraire déjà très accessible. Voici l'html :
C'est justement plutôt accessible ça, surtout que ça utilise les infos de http://schema.org
Avoir une icone devant c'est juste du cosmétique, c'est du style, c'est de l'amélioration mais c'est rien d'autre.
Et pour le côté interopérable je vois pas bien le soucis.
Par contre oui je vais voir pour pouvoir mieux le dégrader si la police n'est pas chargée, ça se serait vraiment mieux c'est vrai.
D'ailleurs on pourrait encore améliorer ceci en réduisant encore plus le couplage entre informations (html) et cosmétique (css)
Le haml pourrait être :
Et le sass deviendrait :
En faisant ceci, la partie icone, style, n'est apportée que par le css, sans aucun besoin html autre que les informations de schema.org.
[^] # Re: Sans javascript
Posté par benoar . Évalué à 3.
Bah si, les fontes custom… Donc ça fait comme sur github avec NoScript, on voit plein de carrés avec le code unicode d'un truc dont on ne sait pas ce qu'il représente. En gros, ça « dégrade » mal.
[^] # Re: Sans javascript
Posté par CrEv (site web personnel) . Évalué à 2.
Oué mais non, les fontes custom c'est absolument pas du js.
C'est du css avec des fontes qui sont, à la discrétion des capacités du navigateur, en
eot
, enwoff
, ensvg
ou enttf
.Je pense que c'est plus noscript qui interdit de charger des fontes externes, mais ce n'est pas du javascript.
Par contre, oui pour la mauvaise dégradation, il faudrait que je vois s'il n'y a pas un moyen de détecter le non chargement de la fonte pour changer de style (le tout en css).
Mais il est vrai que l'usage de ces polices doit être que de l'enrobage, du plus, mais pas du nécessaire lorsqu'on ne maîtrise pas cette problématique.
[^] # Re: Sans javascript
Posté par benoar . Évalué à 2.
Ah effectivement, bien vu, je ne pensais pas que noscript bloquait ça. Vu que quand j'activais javascript, ça apparaissait, je croyais… mea culpa.
Comme disent d'autres plus bas, le meilleur moyen de bien dégrader une fonte, c'est d'utiliser les codepoints standards, au lieu d'utiliser un namespace privé. Comme ça, si j'ai bien l'icône dans ma fonte, ça s'affiche même en dégradé, et si je ne l'ai pas, bah au moins elle est dans ta fonte en mode pas-dégradé.
[^] # Re: Sans javascript
Posté par CrEv (site web personnel) . Évalué à 2.
Et si l'icône n'est pas présente dans ta fonte et en mode dégradé tu as quoi ? Un vieux carré ?
Et pour le fait d'utiliser des "standards", en unicode classique, trouve-t-on tout ce qui est ici : http://fortawesome.github.com/Font-Awesome/ ?
Si non, n'est-ce pas justement le but des namespaces privés ?
Comment je fais pour une icone fullscreen, resize, rss, indent-left, etc ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Table des matières
Posté par CrEv (site web personnel) . Évalué à 1.
La table des matières n'a en effet que peu d'intérêt. Surtout que c'est pas pour être lu autrement que du début jusqu'à la fin (ça m'étonnerais qu'on y retourne chercher des informations ultérieurement).
Par contre, ce que je voulais c'était la mise en forme des titres/sous-titres, et la génération devient automatique.
Peut-être faudrait-il modifier linuxfr pour rendre optionnel la table des matières (voir la réserver, en général, pour les dépêches)
[^] # Re: Table des matières
Posté par oinkoink_daotter . Évalué à 5.
Je seconde. Linuxfr étant lu par des décideurs pressés, il se doit d'être synthétique. Dans cette optique, un execute summary serait de très bon goût.
Cordialement,
[^] # Re: Table des matières
Posté par BAud (site web personnel) . Évalué à 2.
Pourquoi vouloir tuer le sommaire ? Peut-être pensais-tu à un executive summary ? (Abstract étant peut-être moins pédant, quoiqu'anglais, aussi…).
[^] # Re: Table des matières
Posté par CrEv (site web personnel) . Évalué à 2.
Bonne idée pour la position fixe, je verrai peut-être pour le rajouter à ma css
Pour la page principale par contre je crois qu'il faut voir dans le code de linuxfr
[^] # Re: Table des matières
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Je plussoie les deux remarques.
Ce serait plus utile d'avoir une table des matières accessibles via un petit truc qui défile avec la page et qui quand on passe la souris dessus (ou qu'on tape une certaine touche) affiche la table des matières.
[^] # Re: Table des matières
Posté par NeoX . Évalué à 4.
que, si elle n'y est pas deja, ca peut faire une tres bonne entrée dans le suivi
http://linuxfr.org/suivi
# Tout ça !
Posté par ®om (site web personnel) . Évalué à 5.
Pour réaliser (presque) la même chose (une page statique), j'utilise markdown, make, rsync et git. À côté, je suis vraiment un p'tit joueur.
blog.rom1v.com
[^] # Re: Tout ça !
Posté par CrEv (site web personnel) . Évalué à 3.
Oui, t'es vraiment un petit joueur en effet !
Bon sinon, markdown c'est pas mal (et encore) pour remplacer haml si tu veux, pour le reste (sass, coffee) tu ne peux pas.
Et rsync et git sont également utilisés dans mon usine à gaz, rsync est par exemple masqué sous rake
[^] # Re: Tout ça !
Posté par Krunch (site web personnel) . Évalué à 2.
Ah moi j'ai aussi un petit peu de bash et du mod_autoindex.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# page dynamique / web apps
Posté par YBoy360 (site web personnel) . Évalué à 1.
pour ceux qui veulent faire des web app, il y a un truc vraiment sympa, ce sont les web components avec Dart :
http://www.dartlang.org/articles/dart-web-components/
c'est encore expérimental, mais on profite de Dart, après on reconsidère sa façon de faire des web app.
# le vrai avantage de bundler en vrai
Posté par Dreammm . Évalué à 1.
C'est que quand tu fais tourner bundler, certes il consomme le fichier
GemFile
pour savoir ce qu'il doit installer ou mettre à jour, mais surtout il produit le fichierGemfile.lock
.Et que trouve-t-on dans ce fichier ? La liste des versions exactes mise en place par bundler.
Ce n'est pas le cas du magnifique exemple donné, mais si tu as besoin de mettre en production ton œuvre en installant également les bonnes librairies sur ton serveur de production, il suffit d'exécuter bundler sur la machine de production. Bundler va alors réutiliser le fichier
Gemfile.lock
pour installer exactement les mêmes versions que sur ta machine de développement.Et ça, c'est le bien !
[^] # Re: le vrai avantage de bundler en vrai
Posté par CrEv (site web personnel) . Évalué à 2.
Ha oué, c'est un peu ce que j'ai expliqué en fait ;)
Mais d'ailleurs c'est valable aussi en développement, ça permet de s'assurer que tous les environnements sont sur les mêmes version, y compris par exemple tous les environnements de dev.
[^] # Re: le vrai avantage de bundler en vrai
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3.
Et il l'a déjà dit dans le journal tout ça.
# Après avoir tout lu, ma conclusion c'est que...
Posté par Maclag . Évalué à 10.
… je ne ferai plus jamais de site web statique! C'est bien trop compliqué!
N'importe quel tutorial de CMS semble à portée des ignares à côté de tout ça!!
[^] # Re: Après avoir tout lu, ma conclusion c'est que...
Posté par CrEv (site web personnel) . Évalué à 2.
Ha oué mais un CMS pour faire une page statique c'est beaucoup trop bloated comme truc !
Dans le présent exemple il n'y a que le juste strict minimum nécessaire pour faire les choses bien ! Et encore, là on parle d'une page, si on parle d'un site je devrais bien pouvoir rajouter quelques composants ;)
# jquery
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
C'est dommage, ça manque un peu de jquery tout ça (ou autre truc à la mode, je suis peut-être has-been)…
[^] # Re: jquery
Posté par CrEv (site web personnel) . Évalué à 10.
nan mais c'est c'est jquery qui est has-been
J'aurais du probablement l'explicité un peu plus, mais un framework js est utilisé derrière coffeescript. En fait il s'agit d'un framework vraiment révolutionnaire, bien plus révolutionnaire que typescript, encore plus révolutionnaire que snapseed (c'est pas peu dire) ! Le framework qui enlarge vraiment le développement client saïde, c'est évidemment vanilla-js
Depuis que j'utilise vanilla-js mes bugs ont disparu, mes performances sont revenues,
les femmes se jettent sur moi(non ça c'était déjà le cas depuis que je fais des pages oueb)[^] # Re: jquery
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Purée j'ai mis du temps à comprendre !
# Partie 3:
Posté par lendemain . Évalué à 1.
Tu aurais pu faire une troisième partie, qui explique comment tu fais pour faciliter ta génération de contenu (le vrai, celui qui est dans le html)?
Par exemple comment tu fait pour transformer une regex en lien html.
[^] # Re: Partie 3:
Posté par CrEv (site web personnel) . Évalué à 2.
Lapin compris
Où ça une regex ?
Mais sinon, s'il y avait une partie 3 ce serait, par exemple, pouvoir saisir le contenu en markdown avant de l'insérer dans mon fichier haml à l'endroit qui va bien. En plus ça permet de séparer la structure globale de la page de son contenu.
[^] # Re: Partie 3:
Posté par lendemain . Évalué à 1.
C'est une supposition, tu as fait des liens html à tour de bras pour rake, ruby et cie, peut être utilise tu un script qui à partir d'une table [regex -> lien] transforme tout les regex du "contenu" en liens.
exemple [/ruby\>/ -> "< a href=ruby-lang.org />", /rake\>/ -> "< a href=rake.rubyforge.org />"]
Comme il se peut que tu utilise un correcteur orthographique.
C'est certains que pour ce genre de choses, il faut séparer le contenu de l'enrobage html.
ps: le regex \> correspond à une fin de mot/phrase.
[^] # Re: Partie 3:
Posté par CrEv (site web personnel) . Évalué à 4.
Ha non, pour ça il faut juste comprendre markdown :
Un lien s'écrit en général
[texte du lien](url du lien)
Mais on peut aussi séparer la notion de lien (le texte qui va correspondre au lien) et la lien réellement pointé.
Par exemple un lien vers [google].
[google]: http://www.google.com
est équivalent à :
Par exemple un lien vers [google](http://www.google.com).
Mais on peut aller plus loin : déjà à chaque fois qu'on écrit
[google]
il colle le bon lien. Donc déjà, il suffit de ne définir le lien qu'une seule fois pour tout un document.Ensuite, on peut rajouter un
title
:Par exemple un lien vers [google].
[google]: http://www.google.com "Un projet d'étudiants"
Va avoir le résultat suivant :
Enfin, on peut décolérer l'"identifiant" du lien et le texte affiché, par exemple :
Un lien vers [un moteur de recherche][google].
[google]: http://www.google.com "Un projet d'étudiants"
va avoir comme rendu :
De cette manière, on peut taper le texte sans trop se soucier des liens, en perturbant moins la lecture des sources, et en faisant les liens de manière plutôt automatique.
Et évidemment les liens ne sont pas forcément collés au texte, d'ailleurs les miens sont quasiment tout le temps en fin de document, c'est beaucoup plus facile a gérer.
Markdown en ce sens est plutôt bien foutu, il ne lui manque que de vrai notes de bas de page pour être nikel de mon point de vue.
[^] # Re: Partie 3:
Posté par CrEv (site web personnel) . Évalué à 2.
J'en profite :
Pour faciliter la navigation http/https, n'oubliez pas que markdown ne fait que ce que vous lui demandez.
Vous pouvez donc faire des liens relatifs qui laisseront à l'utilisateur la possibilité d'avoir des liens indépendants de http/https.
Par exemple, ce lien doit vous envoyer sur http://linuxfr.org/journaux ou https://linuxfr.org/journaux suivant votre usage.
[^] # Re: Partie 3:
Posté par Sygne (site web personnel) . Évalué à 2.
Je crois que Lendemain parle d'autre chose.
À partir des mêmes sources, on fait un site statique, un document pdf, etc. Du coup, les liens doivent être indépendant du résultat final. On indique les liens de façon simple dans les sources, et on demande à outil de formater ces liens.
Par exemple,
[f.txt](mon lien)
est, dans les sources, un lien vers le fichier f.txt. Lors de la transformation en html, le lien pointe vers f.html. Lors de la transformation en pdf, le lien pointe vers la section 2 du document.Sincèrement, de nos jours, on n'écrit plus ces liens en durs lorsqu'on écrit une page web.
D'où la question : quel outil utilises-tu ?
[^] # Re: Partie 3:
Posté par CrEv (site web personnel) . Évalué à 2.
Hum, pourtant si je relis le commentaire j'en reviens à la même réponse.
Ben heu… dans le cas présent, si.
Aucun.
En fait le sujet présenté c'est vraiment de la page statique, y'a pas autre chose ;)
[^] # Re: Partie 3:
Posté par Sygne (site web personnel) . Évalué à 2.
Et zut !
Moi qui espérait avoir un exemple d'un de ces outils absolument indispensable…
# Deuxième correction
Posté par CrEv (site web personnel) . Évalué à 2.
J'ai oublié celle là… le code coffee est en fait le suivant :
(oui ça change tout…)
[^] # Re: Deuxième correction
Posté par BAud (site web personnel) . Évalué à 2.
Je l'ai changé aussi dans le journal, au bon endroit j'espère…
Mais là pour le coup, c'est un peu la partie qui pourrit la page HTML (et rajoute un ascenseur horizontal), tu aurais mis un lien vers le fichier github, ça aurait pris moins de place (et tu aurais gardé la main dessus :D).
[^] # Re: Deuxième correction
Posté par CrEv (site web personnel) . Évalué à 2.
ha, ça c'est dommage, il faut passer à une autre css :)
Avec la css linuxfr-solarized la mise en page est très correcte, le texte est correctement wrappé et il n'y a pas d'ascenseur horizontal :)
[^] # Re: Deuxième correction
Posté par BAud (site web personnel) . Évalué à 1.
ou envoyer un patch pour la css par défaut, ya ~40000 visiteurs journalier et ~3000 inscrits qui sont les seuls à pouvoir enregistrer leur changement de css facilement :-)
# C'est en lisant des journaux comme ca....
Posté par CHP . Évalué à 10.
… que je me dis que j'ai bien fait de ne pas m'orienter du tout vers les technos web…
PS : pour faire une pages statique, tout le monde sait qu'on utilise MS Word !
# Merci pour le cours
Posté par Ago . Évalué à 1.
Bon maintenant y a plus qu'à.
Et j'attends la partie 3 sur markdown avec impatience :)
[^] # Re: Merci pour le cours
Posté par CrEv (site web personnel) . Évalué à 2.
Va falloir que j'y réfléchisse alors :)
Et au final ça ressemblera alors à un jekyll sous stéroïdes ;)
[^] # Re: Merci pour le cours
Posté par Ago . Évalué à 1.
Oh mais ça a l'air joli jekyll !
Pour info sur le bundle exec guard il y a un warn pour le gem rb-notify en 0.8.8
[1] guard(main)> [Listen warning]:
Missing dependency 'rb-inotify' (version '~> 0.8.8')!
Please add the following to your Gemfile to satisfy the dependency:
gem 'rb-inotify', '~> 0.8.8'
Sauf que quand tu essaie de l'installer il bloque sur le gem ffi.
C'est dommage on perd la partie push auto sur modification, mais bon pas eu le temps de creuser.
# Au bonheur des SSII
Posté par Prndndrd . Évalué à 10.
Ah bah alors là l'écosystème JEE n'a plus qu'à aller se rhabiller devant cette avalanche de frameworks !
Tain j'aimerais bien que tu fasses l'avant vente d'un projet. Tu baragouines tout ça au client, vu qu'il y a plein de choses variées et compliquées le client accepte 20 jours de chiffrage pour ce uber fashion new generation project.
Et l'ingé derrière pouf il te sort la page en une demi journée et faisant du html et css statique.
Gain net impressionnant. J'admire =)
[^] # Re: Au bonheur des SSII
Posté par lendemain . Évalué à 1.
Un ingé pour une page web?
[^] # Re: Au bonheur des SSII
Posté par Misc (site web personnel) . Évalué à 9.
Tu penses qu'il en faut plus ? Tu as raison, faut avoir un ingé et un mec en shadow qui soit prêt à reprendre la techno en cas de problème.
[^] # Re: Au bonheur des SSII
Posté par CrEv (site web personnel) . Évalué à 3.
Ha tiens, bonne idée. Je crois que je vais entamer une reconversion :)
Par contre, faut pas pousser, en JEE on a peut-être autant de frameworks mais au moins ceux que j'ai choisis ne foutent pas à plat un quad core et surtout, j'ai un résultat. J'aurais voulu faire pareil en JEE je crois que je serais encore à l'étape maven (ha ha !) et je n'aurais toujours pas écris la première ligne (et ensuite je ferais ça pour de vrai et j'utiliserai gradle)
[^] # Re: Au bonheur des SSII
Posté par jacobus77 . Évalué à -1. Dernière modification le 07 décembre 2012 à 22:51.
C'est normal que le petit chat sous la souris saute des frames ? C'est pas joli joli.
# dis-nous tout
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 08 décembre 2012 à 10:38.
Penses-tu à un modérateur sur ce site qui rajoute des liens wikipedia, apparemment, dès qu'il peut ? Ou s'acharne sur les tags comme veille technologique comme cela peut se voir sur la page wiki tags et les demandes de suivi afférentes.
[^] # Re: dis-nous tout
Posté par CrEv (site web personnel) . Évalué à 3.
Ha non, ce n'est absolument pas visé contre toi (ni un autre ici). D'ailleurs c'était déjà présent sur mon blog, mais c'est plus une pique (limite private joke) avec des collègues envers quelqu'un (le nommer ne sert à rien) qui ne peut s'empêcher de mettre des liens derrière tellement de mots. Et surtout de placer 10 fois le même lien dans un article (à la première occurrence c'est intéressant, la deuxième rigolo, la troisième franchement lourd alors tout l'article…)
Donc non, c'est pas du tout visé pour toi, au contraire je te remercie de tout ce que tu fais, que ce soit liens ou corrections (et faut dire que j'en ai souvent besoin ;) )
[^] # Re: dis-nous tout
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 08 décembre 2012 à 10:40.
me concernant, je ne m'y reconnaissais qu'à moitié (puis bon, ça ne m'empêchera pas de continuer) ; autant être clair sur les private jokes cela évite de froisser les susceptibilités :-)
boah, ya pas que toi. Puis bon, je le fais avant tout pour moi, c'est un effet collatéral que cela serve à d'autres :D J'ai la possibilité d'éditer, je l'utilise, ça ne va pas beaucoup plus loin (sinon je n'y passerais sans doute pas autant de temps).
Et sinon, pour le concocté, t'as quoi contre le poulet ?
# HAML c'est presque génial
Posté par Badeu . Évalué à 1.
J'essaye toujours de regarder ce qui se fait en contournement pour faire du code HTML ou XMl bien propre, la syntaxe est trop verbeuse et rébarbative au possible et même si mon éditeur futuriste peut faire de la complétion et/ou du remplacement automatique à la volée, c'est un peu du cache misère car je trouve ça toujours un peu frustrant de taper un "A" sur mon clavier pour qu'un "B" s'affiche.
Bref, une notation compilable à la markdown c'est bien, mais le problème du markdown c'est que c'est bien pour écrire rapidement du texte mis en forme, pas plus.
Quand on veut faire un vrai document HTML de compèt HAML c'est top … à un détail près … c'est trop intriqué à Ruby. Si c'était juste une spec, avec beaucoup moins d'intrication avec Ruby, ça pourrait être implémenté de la même manière avec n'importe quel langage et là on aurait vraiment quelque chose qui sortirait du giron de le techno locale.
Le preque génial vient du fait que si on regarde la doc officielle de la notation, il y a juste à retirer quelques fonctionnalités, non vitales, ne pas perdre du vue que HAML sert à générer juste du HTML et tout roulerais.
Ce genre de technologie manque juste un peu d'acmeisme …
[^] # HAML c'est top?
Posté par reno . Évalué à 1.
HAML c'est top?
Bof, moi la syntaxe '%a{"href" => "accueil.html"}' pour un lien (quelque chose d'assez courant quand même en html!) ça ne me parait pas génial, au minimum pouvoir retirer les guillemets ça serait déjà un progrès..
[^] # Re: HAML c'est top?
Posté par CrEv (site web personnel) . Évalué à 2.
en fait il faut prendre ceci comme une map de propriétés mappés sur les propriétés html
On peut d'ailleurs l'écrire comme ceci :
Et là on a bien besoin des guillemets autour de la valeur (mais pas de la clé)
Maintenant, lorsqu'on utilise du
haml
dans rails par exemple, on utilise les helpers fournis par haml et on écris plutôt :De la même manière, pour inclure une balise script de type javascript pointant vers un script extern, façon haml de base :
ou version rails
C'est surtout plus sympa et agréable qu'écrire tout le html à la main, et plus puissant car c'est du templating ruby
[^] # Re: HAML c'est top?
Posté par Badeu . Évalué à 1.
Pourquoi j'ai écrit "presque génial" et "HAML c'est top … à un détail près … c'est trop intriqué à Ruby." d'après toi ? ;-)
C'est exactement pour cette horrible notation là, d'ailleurs celle que CrEv met en avant [1] est beaucoup plus naturelle. Le HAML devrait se réduire à un sous-ensemble des notations qu'il offre aujourd'hui pour fournir quelque chose de "normalisé" et plus cross-technologie.
Allez, va pour un rHAML, reduced HAML, une notation compatible HAML qui est omisciente de la technologie qui l'implémente et du contexte dans laquelle elle est utilisée. C'est l'hiver c'est l'heure de se mettre des projets à réaliser.
[1] :
%a(href="accueil.html" title="Retour à l'accueil")
[^] # Re: HAML c'est top?
Posté par barmic . Évalué à 3.
Il y a quand même un problème quand on en arrive à créer un sous-ensemble plus simple d'un langage conçu pour en simplifier un autre, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HAML c'est top?
Posté par CrEv (site web personnel) . Évalué à 2.
Ou alors le problème initial était bien pire que prévu et à chaque pas on améliore un peu plus les choses ;)
[^] # Re: HAML c'est top?
Posté par Badeu . Évalué à 1.
Pour moi ça essaye de résoudre deux problèmes à la fois qui même si ils se cotoient souvent ne sont pas liés. :
Du coup si on regarde du côté des implémentations différentes de ruby, c'est un peu freestyle ce qu'on peut trouver : entre les implémentations qui reprennent les mécanismes spécifiques ruby à leur sauce (cf. des implems PHP), celles qui essayent de les mapper en 1:1, celle qui essayent d'ajouter des fonctionnalités exotiques (y'a une implémentation en python qui permet de faire des one liners à base de "->", ça m'a juste donné envie de me couper les roupignoles et de me mettre au chant une horreur pareil)
Bref, si la partie ML était séparée de la partie templating, si la partie ML était une spécification avec des outils de vérification, ça éviterait d'avoir un éparpillement des fonctionnalités entre les différentes implémentations (donc les non-codeurs qui font du web pourraient produire du contenu, les codeurs pourraient migrer vers d'autres technos, etc.), ça éviterait que le projet HAML maintiennent 36 fonctionnalités identiques côte à côte comme poid de l'histoire (ex: les passages d'attributs HTML). Ce serait plus clean quoi. Je rejoins donc l'avis de Michel.
[^] # Re: HAML c'est top?
Posté par CrEv (site web personnel) . Évalué à 2.
Ben c'est plutôt facile ça.
Les non-codeurs fournissent leur contenu en markdown, les codeurs l'intègrent dans du haml ;)
(mais sinon tu peux développer un peu plus car je ne suis pas certain d'avoir compris où était le problème…)
[^] # Re: HAML c'est top?
Posté par Badeu . Évalué à 1.
C'est pas vraiment un problème et je vais juste redire ce que je disais plus haut. Mais quand tu as un moteur de template classique, le HTML n'est pas une feature du moteur. Là pour HAML, le modèle de templating qu'il intègre ne devrait pas être une feature, ça "pollue" le côté markup only. Certes tout ça reste très lié mais ça me semble suffisament indépendant pour l'être. Et je pense que ça aurait beaucoup d'intérêt car ça pourrait faire d'HAML une notation à part entière et pas simplement une énième gem ruby qu'on essaye d'imiter partout à côté et qui ghettoise une syntaxe qui a un véritable potentiel.
Et je pense qu'il y a un véritable intérêt à trouver quelque chose de plus efficace que le HTML pour coder. Après ça ne reste que mon point de vue.
# ça manque un peu de latex tout ça
Posté par steph1978 . Évalué à 3.
!!
[^] # Re: ça manque un peu de latex tout ça
Posté par CrEv (site web personnel) . Évalué à 2.
Heu, là comme ça, je répondrais simplement : non.
Et après mure réflexion : non.
Le but est de faire un truc simple, pas un truc tout bloated !
# watch VS git
Posté par MCMic (site web personnel) . Évalué à 3.
Hum, pourquoi ne pas plutôt utiliser un hook («crochet»?) git à la place du guard avec le watch?
Ça me parait plus logique d'associer les commits aux version publiées de la page web. (et ça t'évite un outil de plus dans ton schmillblick à la complexité sans nom pour faire une page web)
[^] # Re: watch VS git
Posté par CrEv (site web personnel) . Évalué à 2.
Il n'y a aucun lien entre les deux.
Un hook peut très bien être rajouté pour publier (
rake deploy
) lorsqu'on push par exemple.Mais guard est là pour voir ses modifications en temps réel.
Si on le place sur un hook, ça veut dire qu'il n'y a que deux façons de voir les modifications apportées :
rake
après chaque modification : sauf que ça veut probablement dire quitter son éditeur pour le faire, puis aller voir le rendu dans un navigateur, revenir dans l'éditeur, faire une autre modification, retourner dans une console, retourner dans le navigateur, etc… alors qu'on peut supprimer cette étape avec guardAu contraire, ce n'est pas du tout si compliqué
Il suffit de prendre un template hyper basique, de faire un
bundle
puis lancerguard
et c'est terminé.C'est justement plutôt dans l'esprit de mixer des outils existant qui font bien leur job, chacun faisant une part du boulot.
(oui par contre c'est presque inutile pour une page web, mais en réalité pas tant que ça, car cela facilite grandement les mises à jour de cette page)
# Et l’accessibilité ?
Posté par tcrxt . Évalué à 2.
Salut,
ton article est vraiment intéressant, c’est précieux de voir comment une personne procède. Le sujet m’interresse vraiment (toujours peur de perdre du temps alors qu’il existe plus simple), je tiens des notes à propos du site d’une association que je développe, les curieux peuvent aller voir à http://micr0lab.org/tech/ et y découvrir LESS (alternative à SASS), syntaxhhighlighter, les sprites, etc.
Je me permets simplement de lister certains sujets dont tu ne dis un mot et qui me paraissent pourtant centraux :
* l’accessibilité,
* les sprites,
* la configuration côté serveur, notamment par le fichier .htaccess,
* les tests du W3C ( http://validator.w3.org/unicorn/ )
* la version mobile
Tu peux consulter à https://reporting.opquast.com/inspector/b.-.J4yjxWm_M~CwbbtLK les règles d’accessibilités qui ne sont pas respectée par ton exemple, parmis lesquelles on peut citer présence de l'attribut alt., d’une feuille de style pour l’impression, d’un fichier sitemap, etc.
Tu écris
Non, les images ne sont pas surfaites, et les fontes graphiques posent des problèmes d’accessibilité, comme expliqué à http://blog.goetter.fr/post/18017100624/icones-font-face-et-accessibilite (qui propose une solution assez lourde à mettre en place).
Pour les plus curieux qui ne connaîtrait pas, trois liens chacun de leur façon sur le sujet du développement oueb : http://www.alsacreations.com/ http://futurefriend.ly/ et http://diveintohtml5.info/
En tout cas merci, je vais maintenant me plonger dans les commentaires et espérer que ce que je raconte n’a pas déjà été dit mille fois (mais après avoir survolé je n’ai pas vu apparaître certains mots clés).
[^] # Re: Et l’accessibilité ?
Posté par CrEv (site web personnel) . Évalué à 2.
Pour commencer, une petite remarque rapide pour mettre les choses au clair :
En fait je n'imaginais pas que quelqu'un pourrait prendre les paroles au premier degré… il y a beaucoup de conneries dans l'enrobage et c'est volontaire.
Centraux pour quoi, pour qui ? Je ne parle initialement (réellement !) que d'une simple page web que j'ai créé, pour un usage très limité - envoi à quelques amis proches - et dans ce contexte ces sujets sont loin d'être centraux)
alt
… sur le nyan cat qui suit le curseur… je ne suis pas sur que ça va gêner qui que ce soit (et là on est vraiment dans le pur exemple bidon donné pour faire la page)(attention à ne pas se méprendre, ces points sont intéressants, mais était assez peu dans l'esprit de mon bla bla, mais j'en rajouterai probablement certains à la partie 3 qui est déjà en route ;) )
Est-ce bien sérieux pour une page ?
Merci pour ce lien. Par contre, je n'aime pas les solutions apportées, même si j'en comprend certains besoins.
Déjà, je ne rajoute pas (contrairement à beaucoup, contrairement à bootstrap, etc) de balise pour ça. Quand je vois du
<abbr>
ou du<i>
pour rajouter une icone css je me dis qu'il y a un problème. Donc ce sera a coup de:before
ou:after
et c'est tout. De même, avoir le caractère stylisé dans l'html n'est pas intéressant. C'est aussi (surtout) mélanger forme et fond. Tant que possible l'html doit présenter le contenu et non la forme. Et les icones, typiquement, devraient être le plus possible dans le css. C'est de l'enrobage et non du fond.Après, ok, à priori
:before
et:after
sont lus, mais comme indiqué à la fin du lien que tu cites, ce n'est pas un problème d'accessibilité. Ok il y a peut-être un peu plus de "bruit" mais le contenu est accessible.Ben de rien, et si tu as des questions n'hésite pas.
Et la suite arrivera bientôt, avec plein de trucs super sympa ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.