20 Apr 2010Imagine the following HTML code :
<div class="wrapper">
[... various HTML elements ...]
<div class="bar">bar</div>
<div class="foo">foo</div>
<div class="bar">bar</div>
<div class="foo">foo</div>
</div>
How would one style the first div.foo
?
I've tried div.wrapper div.foo:first-of-type
but unfortunatly it does not work. In fact the previous rule can be translated into "select the first child of div.wrapper only if it is a div.foo" and not "select the first div.foo inside div.wrapper" as I imagined.
Using jQuery I could do a $('div.wrapper div.foo:first')
but there's no such selector in CSS.
19 Apr 2010The HTML blockquote element can accept a cite attribute that is supposed to hold the value of the source URI of the quote.
Browsers behave differently when getting this attribute in javascript. Opera and Firefox automatically treat it as a URL, prepending the current domain host if none is defined and encoding special characters.
Safari and Chrome on the other end just return the value as it is present in the HTML.
19 Apr 2010When displaying code in an HTML page, you often want it to be correctly indented with tabs. Unfortunatly, setting a white-space:pre
(like is the default on a
element) to an element will transform any tab in the
equivalent of 8 space characters.
8 is way more than needed, 4 will be much suited, specially in a website design where the horizontal space is limited.
I've googled a lot, going from obscure old CSS drafts to proprietary implementation mailing lists, browsing CSS codes.
One interesting discussion can be found here, there even is a proposal for a tab-stops property on the W3C
Opera has a proprietary -o-tab-size
. You just have to pass the number of space characters that should be used.
That's all I have for now...
I know I could replace every\t
with 4
, or with a <span>
that I'll style to match the desired width but it involves a back-end processing and I would have liked to style it directly.
Edit : There seems to have a -moz-tab-size
property on the latest Firefox 3.7 nightlies
13 Apr 2010I'm in the process of tweaking a tinyMCE install to use a custom set of plugins and a custom skin to better fit in the Caracole CMS. This would allow me to re-use CSS and JS code I've already coded.
Fortunatly, I'm getting better and better at understanding the way tinyMCE works and the various configuration options and how to tweak them.
I also want the tinyMCE CSS rules to be integrated into the main CSS file of my app (packed and minified using CSSTidy). So I defined a custom skin in the tinyMCE setup, named 'caracole
'. This way, all the CSS skinning classes will be prefixed with caracole
as I don't want to mess with the default skins.
I also copied the ui.css
file from the themes/advanced/skins/default
to my own css directory, renamed it to tinymce.css
, replaced all .default
occurences to .caracole
and added this file to the list of files being processed by the main packer.
This way I can easily update any css file from the same directory, without having to dive into the tinymce subdirectories.
Unfortunatly, by doing so, tinyMCE continue to load the tiny_mce/themes/advanced/skins/caracole/ui.css
file (have a look at Firebug if you don't trust me). It took me some time to figure out where that call was made from. It is actually on editor_template.js
(around line 150 in dev version).
As I didn't want to load this file twice, I tried to disable this call. I could have manually patched the source file but I don't want to, it would make any future update a pain. So I tried to find an other way.
Looking at the loadCSS
method, it appears that there is a mechanism to prevent loading twice the same file. If the file is already present in the .files
array, it won't be added. Ok, so now I just have to manually add the file before the call is made.
That's where the setup callback come into play. I just defined in my inyMCE.init :
tinyMCE.init({
skin: 'caracole',
editor_css: 'caracoleDoNotInclude',
setup: function(editor) {
tinymce.DOM.files['http://'+document.domain+'/caracoleDoNotInclude'] = true;
}
}
Doing so, the loadCSS
will try to load the caracoleDoNotInclude
file (clearly this name is a placeholder, I have no such file). And in the setup method I manually tell tinyMCE that this file is already loaded so when it will initiate, it won't load the file at all.
Same goes for the content_css
, the file that handle the look and feel of the editable zone. I don't want to have my file in the tinyMCE skin directory, I'd rather have it with my other CSS files.
So I defined a custom content_css
to point to my file. I also had to update the setup method to mark the file as already loaded. But this time, as the file is loaded on a per instance basis, this is the editor.dom.files
that I have to update, not the general tinymce.DOM
.
Fortunatly, the latest tinyMCE version expose their event API, so it was just a matter of defining the following event in the main setup :
setup: function(editor) {
tinymce.DOM.files[baseUrl+'caracoleDoNotInclude'] = true;
editor.onPreInit.add(function(editor) {
editor.dom.files[baseUrl+'js/vendors/tiny_mce/themes/advanced/skins/caracole/content.css'] = true;
});
}
Edit :
Note that in the latest tinyMCE version, the code is slightly different because you have to call a special method on the url before adding it to the editor.dom.files
editor.onPreInit.add(function(editor) {
editor.dom.files[editor.baseURI.toAbsolute('http://'+document.domain+'/js/vendors/tiny_mce/themes/advanced/skins/caracole/content.css')] = true;
});
12 Apr 2010If you try the following code in Opera 10.51, you'll have some weird rendering bug :
<style>
.test:after {
content:"This should be on red background";
background:red;
}
</style>
Text input : <input type="text" value="I'm unstyled" class="test" />
The generated content is added to the page, but the background color isn't rendered. Worse, the input lose all styling, it does not have a background color nor borders anymore.
The same effect also apply to every input
(radio
, checkbox
and password
).
On a select
tag, the generated content correctly have it's background color, but still lose all styling.
On a textarea
, the styling is gone too, and the background color is here. Well, sort of, it is actually cropped after a while and the end of the text is on transparent background.
I sent a bug report to Opera about that.