lillbra.se

Arkiv för February, 2011

Så tillåter du HTML5-element i TinyMCE

Den populära WSIWYG-editorn TinyMCE är default-inställd på att rensa html-koden från ogiltiga html-taggar och -attribut (cleanup-metoden). Och i default-inställningarna på vilka html-element som är tillåtna finns inga av nyheterna i HTML5. Så när html-kod infogas eller modifieras i editorn kommer TinyMCE att ta bort nya HTML5-element och -attribut.

Men detta kan du ändra på. Det enklaste och bästa sättet att tillåta andra element är att definiera extended_valid_elements i TinyMCE-inställningarna. För att, till exempel, tillåta <time>-taggen med ett datetime- och data-attribut skriver du följande:

tinyMCE.init({
...
extended_valid_elements : "time[datetime|data-is-start]"
});

TinyMCE i EPiServer

Om du utvecklar för EPiServer måste du göra dessa TinyMCE-inställningar genom EPiServer. Det gör du genom att skapa en klass med TinyMCEPluginNonVisual-attributet:

using EPiServer.Editor.TinyMCE;
namespace Customer.Web.Plugins.TinyMCE
{
[TinyMCEPluginNonVisual(AlwaysEnabled = true, PlugInName = "ExtendedValidElements", EditorInitConfigurationOptions = "{ extended_valid_elements: 'time[datetime|data-is-start]' }")]
public class ExtendedValidElements
{}
}

Och i din episerver.config-fil lägger du till (via Frederik Vig):

...
<tinyMCE mergedConfigurationProperties="valid_elements, extended_valid_elements, invalid_elements, valid_child_elements" />
</episerver>

TinyMCE i WordPress

Om du använder WordPress så gör du dina TinyMCE-inställningar i en egen funktion som du lägger till som ett filter med namnet tiny_mce_before_init. Detaljer om hur du gör detta hittar du här: Adding html5 capability to WordPress.
Lycka till!

Mer på lillbra.se om: , , , ,

Andra bloggar om om: , episerver , html5 , tinymce , wordpress

Veckans länktips – 2011-02-13

Prestandaoptimering inom css

Som frontend-utvecklare hittar man ofta tips och bloggposter om hur man bör optimera javascript för få bättre prestanda. Men att känna till hur man kan förbättra css-selektorer och -regler kan också vara bra.
För att avgöra vad som är prestandaslukande css, så är det ett par grundläggande saker om webbläsare man ska veta:

Utseendet för ett element bestäms då det skapas
Webbläsaren läser och ritar ut ett element i taget, med start uppifrån och ned i html-dokumentet. För varje element som ritas ut, avgör webbläsaren om den dessutom måste rita om tidigare element.
Se en video på hur en sidrendering i Firefox ser ut i slow motion här (via Snook).

Css-selektorer evalueras från höger till vänster
Nyckeln i en css-selektor är det som står längst till höger. Webbläsaren börjar tolka selektorn från höger och fortsätter sedan tills den kan avgöra om utseendet ska appliceras på aktuellt element. Ju fler noder måste evalueras för att se om regeln stämmer för elementet, desto mer jobb är det för webbläsaren.

Med detta som bakgrund ger Google Page Speed följande råd till hur du skriver effektiva css-selektorer:

Undvik universalselektorer
Nycklar som matchar alla element är självklart krävande. Använd ej: body * {...}

Gör regeln så specifik som möjligt
Id:n är mest effektiva, följt av klasser och sist taggnamn och universal-selektorer. Använd t.ex. klasser och id:n som nyckel istället för taggnamn. Jämför följande: #comment p {..}
#comment .text {}

Undvik redundanta selektorer
Låt klasser och id:n tala för sig själva, skriv inte kombinationer när de inte behövs, som t.ex.: div#comment
p.text

Undvik descendant selektorer
Håll selektorerna korta, och ha inte med förälderelement som gäller för alla element, t.ex.: body ul li a {...}

Undvik :hover pseudoe-selektorn för element som inte är länkar i IE
Kan orsaka problem i Internet Explorer 7 & 8, överväg att använda javascript istället.

Undvik css-expressions
Stöds bara av Internet Explorer och är deprecated. Använd media-queries eller javascript istället.

Hur stor effekt det ger att följa ovanstående råd är såklart olika från fall till fall. Men speciellt mobiler och läsplattor är inte så kraftfulla och där kan optimering ge märkbar effekt. Tomas Fuchs har kollat närmare på vilken sorts css som slöar ned renderingen på iPaden, och främst är det nyheterna inom css3 som orsakar problem. Enligt honom bör vara försiktig med att använda följande:

text-shadow och box-shadow
Krävande och slöar ned sidan kraftigt.

-webkit-gradient
Webbläsaren skapar en bitmap av gradienten vilket inte är optimalt. Istället kan man använda canvas till att måla stora gradienter.

-webkit-transform
Orsakar hårdvaruacceleration, och är buggigt.

opacity
Genomskinligheten kan tydligen störa hårdvaruaccelerationen och på så sätt orsaka långsam sidladdning.

Till sist: Prestandaoptimeringar i all ära, men kom ihåg att inte offra semantiken för att skriva snabbare selektorer. Att sätta id:n på alla element är alltså ett no-no – skapa en ren semantisk html i första hand :) Och för dig som vill läsa mer kan jag rekommendera följande artiklar:

Relaterade artiklar på lillbra.se:

Page 2 of 3«123»
Rullar på Wordpress med modifierat Guerrilla-tema