[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: CSS Media="print" support problems
From:       Lars Knoll <knoll () kde ! org>
Date:       2001-09-21 16:13:18
[Download RAW message or body]

It's unfortunately not that easy, as there are several cases we have to look 
for. The simple and obvious one is when a whole stylesheet has a certain 
mediatype as in <link rel=stylesheet sr=... type=print> (hope I remember the 
syntax correct). But you can mix different media typed in one style sheet, as 
in

foo { color: red }

@media print {
	 foo { color: blue; }
}

@media screen {
	foo {color: green; }
}

To be able to handle this correctly, we need a correct implementation of the 
MediaRule in the DOM, and cssparser. After that we could add a parameter for 
the media to the construtor of the CSSStyleSelector, which would only pick up 
matching rules.

It's on my todo list since ages, but I didn't find the time to work on it up 
to now (unfortunately almost no time at all for khtml in the last 2 months). 
Feel free to try to implement this. 

Cheers,
Lars


On Friday 21 September 2001 12:12, Martijn Klingens wrote:
> For the project that I'm working on it would be very nice if KHTML could
> distinguish between media="print" and media="screen" for CSS.
>
> But while digging through the code I am not exactly sure where I should
> look.
>
> (The following talks about KDE 2.2 branch - I hope this also applies to
> HEAD. Actually, I'd like to know the current differences between 2.2 and
> HEAD regarding KHTML's infrastructure. I only this morning finally decided
> to subscribe to kde-cvs ;-)
>
> Anway, here goes:
>
> I found that in html/html_headimpl.cpp the HTMLLinkElementImpl::attach()
> method already looks for the media type... and then does nothing special
> with it.
> Obviously the media type should be stored somewhere so it can later be
> queried by CSSStyleSelector::styleForElement (at least, I think this is the
> method that actually applies the CSS, but hey, I'm new to KHTML...).
>
> For the Link element's implementation it would be enough to store the media
> type in the CachedCSSStyleSheet class or something similar. But that
> doesn't work for the @media element that is allowed inside CSS data. So I'd
> rather go for a more generic approach that can be extended in that
> direction.
>
> The most important question that I have now is basically a "where can I put
> these changes so that they actually work?".
>
> Also, are there some generic pointers to the classes that I should
> particularly look at? KHTML doesn't seem too difficult to me, but it
> consists of an awful lot of classes, so it is still quite a complex beast
> to grab at first. Each single class is remarkably simple, but the overall
> picture could IMO seriously use a class tree or even UML chart that shows
> how all classes relate to eachother...
>
> Finally, I need this for my work, and for now this project is not planned
> to be developed against CVS HEAD. In other words: I am not using HEAD
> either. This will obviously sooner or later result in problems. But I
> vaguely remember reading that KHTML from HEAD still compiles against 2.2
> branch. Is that true? How can I setup such a thing? Just cvs up -A in
> khtml, or is there more to it? If this doesn't work, any other clues on how
> to make it possible to forward-port the code (if I get it working ;-) to
> HEAD with the minimum amount of fuss?
>
> Lots of questions here, I almost feel like the newbie I was 10 months
> ago...
>
> Thanks in advance for any hints and other help,
>
> Martijn

[prev in list] [next in list] [prev in thread] [next in thread]