Item11656: Pattern skin font definitions are too far into the html to work for JQDialogs
ok, this might be fat willy specific
the fat willy theme used on f.o does not over-ride the plain theme, so any fixes in the plain theme are not reflected here
- and the plain theme style.css has the fonts set on
on my 1.1.4 I was having issues, but they might have been the jquery theme setting, but thats another story.
adding @import to each is said to be bad, and does break rendering
so I've pasted the top of the general style.css into the top of the fatwilly theme style.css - as this seems to work
need review though
- 16 Mar 2012
I am trying to learn from your change. But I don't know what problem you ran into. Where can I test this JQDialog?
- 25 Mar 2012
sorry, that wasn't very nice of me
- which is used for the 'Create Task' link at the top of the Tasks web side bar.
There's also a NEW Task link under it that I've enabled for you (its hidden for most people as I was 'testing'
in the first example, you can see the
style that I added to reduce the weirdness.
basically, imo, all the rendering defaults - like font-family, size, most used font colour etc are best off being set at the html body, so that everything (irrespective of lack of foswiki* class) gets rendered consistently.
its the same grip i have about tables - I cannot understand why we're not styling table, th, tr and td first, and then only add more juice for foswikiTable elements.
- 26 Mar 2012
I see. jQuery UI creates a div alongside
, and as you write, some styles are not set at
. This was done on purpose, so external css would not interfere with pattern css styles. But it is not consistent and it is giving more problems than what it should be solving.
Regarding tables, for a long time page markup has been done with tables. So styling table cells would create unwanted borders and backgrounds. On the other hand, it would have revealed bad html practice. So I agree this should be done as well.
- 09 Apr 2012