Tag HTML personalizzati: ci sono delle specifiche che indicano un modo standard per gestirle?

4

Sembra che da anni abbiano appena ricevuto uno stile predefinito e una visualizzazione in linea. C'è una specifica da qualche parte che ha dettato questo? Ho esaminato le RFC, ma non sono particolarmente adatto a RFC, e non ho notato nulla da nessuna parte.

Ad esempio

<body>
   Some content <mycustomtag>something else</mycustomtag> more content.
</body>

Posso ancora modificarlo con i CSS , e il browser non vomita completamente ... quindi sembra che ci sia qualcosa tipo di comportamento previsto. È stato dettato da una specifica?

    
posta blesh 30.10.2012 - 19:21
fonte

2 risposte

5

HTML 2.0 (RFC 1866) dice, in Gestione degli errori di markup non dichiarati : "Per facilitare la sperimentazione e l'interoperabilità tra le implementazioni di varie versioni di HTML, la base installata di agenti utente HTML supporta un superset del linguaggio HTML 2.0 riducendolo a HTML 2.0: markup sotto forma di tag di inizio o fine -tag, il cui identificatore generico non è dichiarato è mappato su nulla durante la tokenizzazione. - - I fornitori di informazioni sono avvisati che questa convenzione non è vincolante: può verificarsi un comportamento non specificato, in quanto tale markup non è conforme a questa specifica. "

Ciò significa che i tag sconosciuti vengono ignorati. Qualsiasi dato tra di loro viene elaborato normalmente. Cioè, i tag vengono saltati, l'elemento (asserito) non lo è: il suo contenuto viene gestito come se i tag non fossero lì. Quindi, invece di essere trattati come elementi inline, i costrutti sono stati trattati come content .

L'HTML 2.0 è un grande miglioramento rispetto ai suoi successori in termini di chiarezza ed esattezza. Ma ciò che è accaduto in pratica è che i browser iniziarono a riconoscere elementi con tag non definiti, creando nodi di elementi nel DOM e rendendoli disponibili per lo stile e lo scripting lato client. IE è l'ultimo a seguire l'esempio qui (come così spesso), e in Quirks Mode, anche IE 9 ignora i tag sconosciuti (non crea elementi stilizzabili), a meno che non si usi document.createElement() per "definirli".

In XHTML, le cose sono diverse in linea di principio. Sebbene le specifiche XHTML siano oscure, è apparentemente l'idea che XHTML sia solo XML con tag legati a "namespace HTML". Cioè, puoi usare qualsiasi tag in XHTML e quelli dichiarati nello spazio dei nomi HTML saranno interpretati usando la semantica HTML, altri elementi provengono da altri spazi dei nomi noti all'implementazione (ad esempio, spazio dei nomi MathML o SVG) o senza alcun spazio dei nomi, essendo solo tag XML - che creano ancora nodi (stilizzabili) nel DOM.

    
risposta data 30.10.2012 - 20:00
fonte
4

La risposta di Jukka copre bene le specifiche esistenti, solo per completezza vorrei dire che lo stesso recente "Introduzione ai componenti Web" la bozza W3C include elementi HTML personalizzati ( il nome corretto è elementi, "tag" si riferisce al tag di apertura e chiusura).

Dalla bozza:

2 Introduction

The component model for the Web (also known as Web Components) consists of four pieces designed to be used together to let web application authors define widgets with a level of visual richness not possible with CSS alone, and ease of composition and reuse not possible with script libraries today.

These pieces are:

  • templates, which define chunks of markup that are inert but can be activated for use later;
  • decorators, which apply templates to let CSS affect rich visual and behavioral changes to documents;
  • custom elements, which let authors define their own elements, including new presentation and API, that can be used in HTML documents; and
  • shadow DOM which defines how presentation and behavior of decorators and custom elements fit together in the DOM tree.

...

5 Custom Elements

Custom elements are new types of DOM elements that can be defined by authors.

Custom elements can define presentation aspects like decorators. Unlike a decorator, which can be applied or unapplied to a given element, the element's type is fixed. So custom elements can also define new state and behavior, which decorators can't do because of their ephemeral nature.

The element element defines a custom element. It specifies the type of element it's a refinement of using the extends attribute:

   <element extends="button" name="x-fancybutton">
       …
   </element>

Puoi monitorare lo stato della bozza qui . Il progetto è guidato dal team di sviluppo di Google Chrome :

The Web Components project , led largely by the Google Chrome development team, aims to help solve a simple problem: Building Web applications is more complicated than it used to be. Worse, it's more complicated than it should be.

Modern Web apps have rich, interactive UIs, driven largely by client-side code. Today we generally build such UIs using JavaScript frameworks and UI toolkits, such as Dojo/Dijit, jQuery UI, and YUI. That's both good and bad. It's good because it means it's now easier to build rich Web UIs than ever before. It's bad because it needlessly shifts the balance of control over Web development from designers to programmers.

    
risposta data 31.10.2012 - 08:48
fonte

Leggi altre domande sui tag