Reprise du message précédent :

 
Dans ce cas il faudrait englober le truc d'un commentaire de début et de fin pour marquer le fait qu'on veut rester en oneliner.

oui donc CSS.
Tu peux virer le tableau dans lequel t'as encapsulé le pre et styler les pre avec des propriétés CSS comme border, background-color, ...
Si tu as besoin de différencier visuellement certains pre leur ajoutes des classes (à ajouter en attribut dans le html) et tu les styles.

Vous auriez un .htc à me conseiller pour la transparence png sous IE6 ?

non, je veux qui mette les espaces correctement dans le oneliner et l'indentation avant quand même

edit: en fait tout ça c'est des trucs qui existent en java

HAH LIES TU PEUX PAS FAIRE DE ONE-LINER EN JAVA, TU FAIS DES ONE-PAGER!

 
YOU CAN BUT IT'S A HELL OF A LINE LOL

Confond pas avec XSLT

dites les jeunes, j'ai un pb d'interface, de vocabulaire etc.
 
Dans mon site, j'ai décidé de faire de l'engagement progressif, on peut créer une carte sans créer de compte, du coup je stocke un cookie dans le browser depuis ce browser on peut éditer la carte. Ensuite j'ai créé une page où si on est loggé, on peut revendiquer des cartes qui sont associées au browser (pour les faire passer de cookie à compte).
 
Comment vous appelleriez une carte associée au browser ? une carte associée à un compte ? comme vous appelleriez l'action de passer de l'un à l'autre ?  
Le but n'est pas de trouver un vocabulaire techniquement aussi précis que possible (moi ça me dérange pas de symboliser du filtrage par un entonnoir, même si techniquement c'est faux), mais faire capter à des noobs un modèle pas trop loin de ce qu'il va se passer.
 
Est-ce qu'il existe des conventions que je peux réutiliser ? j'en trouve pas là tout de suite.

C'est pour leur afficher un message d'explication ? Ou ça va plus loin que ça ? Parce que sinon un message con du genre :

y'a une page avec la liste des cartes du navigateur et un bouton pour les ramener sur le compte aussi.  
Il faut un titre à cette page, et un label sur le bouton.
et aussi un lien à mettre vers cette page.
 
et si possible en évitant les phrases longues parce que ça fait chier tout le monde.

- Cartes temporaires :

• carte 1 [enregistrer]
• carte 2 [enregistrer]
• carte 3 [enregistrer]

- Cartes enregistrées

• carte 4
• carte 5
• carte 6

Pareil, le simple mot/concept "enregistrer" me semble suffisant.

cartes enregistrée sur cette ordinateur
- (une icone  w()()sm/\pa vec un title "enregistrer dans mon compte "  )
-
-

cartes enregistrées dans votre compte w()()sm/\p

Ou alors, tu fais le bourrin, tu transfère tout

 
Moi j'aurais plutôt vu ça comme ça oui, d'où mon premier message.
 
Inciter les gens à créer un compte pour garder leurs maps. Après ils peuvent toujours supprimer celles qu'ils ne veulent pas.

voir une page ( lors de la création du compte) afficahnt les cartes récupérés et un bouton pour les supprimer

mon système provoque un risque nouveau : le fait de créer une carte en ayant oublié de se logger.

Quelqu'un a de l'expérience avec l'api DOM de php ?
Je crée un doc avec plusieurs namespaces, que je valide avec un schéma.  
J'arrive pas à créer un DOMDocument qui ait un namespace lui même, du coup il faut que je créer toooous les éléments avec createElementNS, même ceux qui sont dans le même namespace que le document lui même, sinon la validation xsd ne passe pas.
Le truc pas cool c'est les 150 lignes de code de la forme
$document->createElementNS('http://un.putain.de.namespace.chiant', 'Element); j'aimerais bien éviter la répétition

Tu aliase createElementNS? Parce que ça me semble être le fonctionnement normal d'un DOM tiré de celui du W3C.

 
C'est un peu la seule solution que je vois
 
Mais je trouve pas ça super logique parce qu'une fois sérialisé ton DOM, que tu ait créé avec createElement ou createElementNS, le xml sera le même.
Donc si t'as un dom avec des éléments sans namespace, tu valide directement ton dom ça échoue, tu sérialise/parse/valide ça passe.
Au moment de la sérialisation les éléments sans namespace sont considérés comme appartenant à celui par défaut mais pas au moment de la validation, c'est pas super cohérent

Alias createElementNS ouais

Si c'est le cas, ta lib pêtée. Un élément créé avec createElement devrait ne pas avoir de namespace du tout (null namespace), pas avoir un namespace par défaut.

wtf...

edit: sarace, lxml fait pareil

PHP \o/
Bon après, derrière c'est la libxml, mais c'est pas la première fois que le wrapper php fout la merde au milieu...
 

Ça a l'ai d'être libxml, lxml a l'air d'avoir le même comportement à la sérialisation Enfin la sémantique a l'air vraiment bizarre (dans lxml j'veux dire) et un micropoil vomitive.

Bon ben y'a un bien un bug dans la sérialisation si je comprends bien la norme, mettons que je veuille créer 3 éléments imbriqués dans le même namespace:
 
Si je crée bien les 3 éléments avec createElementNS :

<A xmlns="http://name.space">
  <B>
    <C>value</C>
  <B>
<A>

Si j'oublie le namespace sur <B>, ça se sérialize en :

<A xmlns="http://name.space">
  <B>
    <C xmlns="http://name.space">value</C>
  <B>
<A>

Ce qui s'interprète normalement comme "B" est dans le même namespace que "A", et le namespace de "C" est redondant, il faudrait plutôt avoir:

<A xmlns="http://name.space">
  <B xmlns="">
    <C xmlns="http://name.space">value</C>
  <B>
<A>

 
Mais quand même, je trouverais plus pratique que quand tu crée un élément avec $document->createElement, il ait par défaut le ns du document

Bah ça a pas vraiment de sens, et de toute façon un document XML n'a pas de namespace intrinsèque Çe que je trouverais logique (mais pas nécessairement pratique), c'est que createElementNS pète si tu lui donnes pas de namespace, et qu'à la sérialisation ça pête si t'as un mix d'éléments namespacés et non namespacés et un namespace par défaut (ou alors que ça pête si t'as un mix, histoire d'être sûr, avec possibilité d'overrider pour sortir du mixed)

edit: il est bizarre que ton serializer mette un namespace explicite sur C, il a aucune raison de le faire, il devrait mettre un xmlns sur A et c'est tout. Et je suis un peu choqué qu'il mette le premier ns qu'il trouve en default namespace aussi.

Un document n'a pas de namespace intrinsèque, mais il a une racine unique avec un namespace.
Quand tu crée un DOMDocument via DOMImplementation tu peux spécifier le node racine et son namespace.
Les DOMDocument ont une propriété namespaceURI, mais elle est en readonly et est toujours à null

Bah sa raison c'est que pour lui, vu que B et C n'ont pas le même namespace (celui de B est null), il faut spécifier celui de C. Sauf que forcément une fois sérialisé ça ne se voit pas.
 
Pour le premier namespace, ça ne me choque pas, je vois pas de cas particulier à appliquer à la racine, elle a un namespace, il est différent du parent (vu que le parent existe pas), donc on spécifie ce namespace.

Oui mais ça n'en fait pas le namespace du document.

Elle est héritée de Node

Et sa définition est:

Ah oui pas con. Par contre dans ce cas la sérialisation devrait pêter, vu qu'elle peut pas distinguer un namespace null d'un namespace par défaut.

Je ne trouve pas bizarre de donner un namespace, je trouve bizarre qu'il le mette en namespace par défaut. ElementTree et lxml donnent un namespace arbitraire (ns\d+, en fait) si on ne configure pas explicitement le namespace par défaut, ça me semble moins risqué justement à cause du risque de mix entre default et null namespace. Sauf à avoir démontré par avance que le null namespace n'est utilisé que par des attributs (puisque les attributs n'héritent pas du default namespace)

Juste comme ça, c'est quoi tes namespaces exactement ? J'ai parfois eu des bizarerries avec http://www.w3.org/1999/xhtml si je me souviens bien

j'pense qu'il est dans le KML et le google là

Indeed, et j'aurais bien aimé ne pas avoir à apprendre tout ces détails sur les namespaces xml...

J'pense qu'on est tous passés par là (ceux qui ont eu à comprendre les namespaces en tout cas), ça résout un vrai problème et l'idée (dans la mesure où c'était pas supporté de base dans XML) est pas con, mais c'est plein d'edge-cases, les implémentations sont à chier, ça manque de consistance (attributs vs éléments), c'est ultra mal branlé quand le namespace est *du contenu* (genre valeur d'un attribut et pas infoset) et dire que l'abstraction a des fuites est *très* gentil.

Et je passe sur les systèmes "XML" qui hardcodent le préfixe du namespace (genre soap, tu peux — ou en tout cas pouvais il y a quelques années — pas utiliser un autre préfixe que "soap" ou ça te pête à la gueule, me semble que maven faisait chier là dessus aussi par un moment)

Nota: le jour ou j'ai découvert "Clark's notation" j'ai beaucoup mieux compris le principe derrière les namespaces.

Le contenu de ce message a été effacé par son auteur

ton designer est un con, il n'a pas à la mettre dans une fonction qui est lancée au domready.
quand on fait  

Le $ est une méthode de jquery, et quand on lui passe une fonction en paramètre. Cette fonction sera lancée au "domReady", donc quand tout le html de la page sera chargé.
 
Donc tout ce qui est dans cette fonction sera éxécuté au chargement de la page. Donc c'est débile de déclarer une function dans une fonction anonyme.
 
Il faut la sortir de là. Surtout si elle doit être utilisée ailleurs, sa portée doit être globale.
 
Jette ton designer.

Le contenu de ce message a été effacé par son auteur

C'est quoi le display d'origine d'un TR ?

c'est dans les trucs arcanes de CSS2 : table-row j'ai jamais vu personne jouer directement avec sans faire une table, parce que c'est pas supporté par IE.
 

Merci

http://www.w3.org/International/qu [...] onal-names

 
Super intéressant, je forwarde de suite à ma team de BA...
 
On a eu le problème avec JP (ordre nom pénom, et le fait de devoir accoler le symbole "-san" )

Ze Dong, lol.