[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-23 12:10:33
[Download RAW message or body]

On Friday 21 September 2001 23:29, Martijn Klingens wrote:
> On Friday 21 September 2001 18:13, Lars Knoll wrote:
> > 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.
>
> I guessed so. The code is not entirely clear yet, though I seem to
> understand most of it globally. What class did you have in mind to put the
> media rule?

Have a look at the DOM2 specs (the chapter about style sheets and css:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/ ).
We are implementing that interface to a good degree. They also have a class 
representing @media rules

The class we need to implement and add suport for is the CSSMediaRule 
(actually CSSMediaRuleImpl). It is currently mostly made out of function 
stubs that do nothing, and the cssparser more or less ignores media rules 
(ie. it ignores every media rule that does not have type "all" or "screen"). 

Currently a style sheet as the one above would result in a parsed DOM 
representation similar to:

CSSStyleSheet
	CSSStyleDeclaration // foo
		CSSProperty // {color: red }
	CSSStyleDeclaration // foo (in @media screen)
		CSSProperty // { color: green }

while it actually should be creating a tree like the one below:

CSSStyleSheet
	CSSStyleDeclaration // foo
		CSSProperty // {color: red }
	CSSMediaRule // @media print
		CSSStyleDeclaration // foo
			CSSProperty // {color: blue }
	CSSMediaRule // @media screen
		CSSStyleDeclaration // foo (in @media screen)
			CSSProperty // { color: green }

After that we have to add a flag to the CSSStyleSelector at creation time 
telling him which media it is for (an enum { Screen, Print } is probably the 
best for the moment). and parse out the CSSStyleDeclarations in the 
approriate meda sections.

> > 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.
>
> If I get some pointers in the right direction then I'll try that monday at
> work. I do have a deadline for my project and if it takes too much time
> then I will have to find another solution.

Hope the above helps you here.

> BTW, does this mean that it breaks BC? Because in that case I am forced to
> switch to CVS HEAD or being unable to actually commit the code. Neither of
> which I particularly like for this project.

It doesn't break binary compatibitly, as the *Impl classes (and the 
CSSStyleSelector) are the only placesyou should neeed to change the API, and 
tehse ones are internal to khtml. But still I don't want these features to 
come into the 2.2 branch. It's amajor feature change and chances are very 
high it'll break something at the beginning. Correctly parsing style sheets 
is a rather tricky thing.

> I don't have time to do this in my spare time, so it will be under the
> cover of my (closed source) kiosk application, with the associated
> restrictions as opposed by my company. (The only important restriction is
> that any code that is clearly aimed at kiosk apps may not be made open
> source, which is luckily not the case here - I may make fixes to KHTML and
> obey the LGPL license there so we can all make use of this stuff.)

You have to, as the license says. LGPL means that your company needs to open 
source all changes you made to khtml (for whatever reason you did so). Only 
things that are in a different library or in the app itself can be kept close.

Cheers,
Lars

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