[webkit-dev] Qt Mac buildbot got crazy

[Osztrogonac Csaba]

Hi All,

it seems Qt Mac bot got crazy and signals false build fails regularly:
../../../../Source/WebCore/bridge/qt/qt_runtime.cpp: In function 'bool 
JSC::Bindings::isJSUint8ClampedArray(JSC::JSValue)':
../../../../Source/WebCore/bridge/qt/qt_runtime.cpp:142: error: 
'JSUint8ClampedArray' is not a class or namespace

Please ignore this message.

Alexis, could you stop your bot not to confuse folks with false alarms until 
proper fix?

br,
Ossy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Dirk Pranke]

On Fri, Apr 27, 2012 at 5:17 PM, Maciej Stachowiak  wrote:
>
> I think the concern is that, due to lack of clear standards, we end up not 
> knowing when we can remove things. Thus, we end up with a lot of inconclusive 
> and frustrating conversations, and people may shy away from even trying to 
> remove things.
>

My concern is to clarify our stance is on removing features with
vendor prefixes once the non-prefixed version has been implemented.
That is a subset of the general "when can we remove a feature after
we've shipped it" problem.

Reading Julien's summary, it sounds like the stance for webkit will be
"we won't (and shouldn't) remove a feature unless it is causing us
(webkit devs) enough pain that it would justify potentially breaking
pages".

Obviously, some people believe that this is not how vendor prefixes
are supposed to work; that we are supposed to remove support for
vendor prefixed features at some near-ish time after the unprefixed
version has shipped.

At the very least, by not being clear about what our process is, we
make it very hard for the html teachers of the world (evangelists,
book authors, etc.) to convey an accurate message to their audience,
and we risk misleading html authors as well.

> BTW, the page at  seems to 
> be using "deprecate" in the sense of "remove entirely". Is that what is 
> meant? If so, I think it would be helpful to change the wording to "removing 
> features". In non-Web contexts, deprecate often means a step short of removal.

I agree that "Removing features" is clearer and more to the point :).
When to deprecate features in the sense of "we recommend you use this
other feature instead" is an entirely different conversation.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Eric Seidel]

Not having been to the meeting (but having read
https://trac.webkit.org/wiki/DeprecatingFeatures), it struck me as
though we were trying to add process (like we did for adding features
last year), to deter deprecating things.

On Fri, Apr 27, 2012 at 5:14 PM, Benjamin Poulain  wrote:
> On Fri, Apr 27, 2012 at 5:10 PM, Eric Seidel  wrote:
>> Is the concern that we've been deprecating too many things too quickly?
>
> Quite the contrary. People were concerned about the way to deprecate
> more stuff and making fewer mistakes when adding and removing features
> :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Maciej Stachowiak]

I think the concern is that, due to lack of clear standards, we end up not 
knowing when we can remove things. Thus, we end up with a lot of inconclusive 
and frustrating conversations, and people may shy away from even trying to 
remove things.

BTW, the page at  seems to be 
using "deprecate" in the sense of "remove entirely". Is that what is meant? If 
so, I think it would be helpful to change the wording to "removing features". 
In non-Web contexts, deprecate often means a step short of removal.

Regards,
Maciej


On Apr 27, 2012, at 5:10 PM, Eric Seidel  wrote:

> Is the concern that we've been deprecating too many things too quickly?
> 
> On Fri, Apr 27, 2012 at 5:00 PM, Benjamin Poulain  wrote:
>> On Fri, Apr 27, 2012 at 2:18 PM, Dirk Pranke  wrote:
>>> That said, what sort of "officialness" does this
>>> writeup/guideline/policy have? Do all the ports agree that this is
>>> what our stance should be?
>> 
>> Everyone seemed to agree we just need to discuss each deprecation on
>> webkit-dev with solid supporting data.
>> 
>> Feel free to continue the discussion on this mailing list if you have
>> ideas for improvement.
>> 
>> Benjamin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Benjamin Poulain]

On Fri, Apr 27, 2012 at 5:10 PM, Eric Seidel  wrote:
> Is the concern that we've been deprecating too many things too quickly?

Quite the contrary. People were concerned about the way to deprecate
more stuff and making fewer mistakes when adding and removing features
:)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Eric Seidel]

Is the concern that we've been deprecating too many things too quickly?

On Fri, Apr 27, 2012 at 5:00 PM, Benjamin Poulain  wrote:
> On Fri, Apr 27, 2012 at 2:18 PM, Dirk Pranke  wrote:
>> That said, what sort of "officialness" does this
>> writeup/guideline/policy have? Do all the ports agree that this is
>> what our stance should be?
>
> Everyone seemed to agree we just need to discuss each deprecation on
> webkit-dev with solid supporting data.
>
> Feel free to continue the discussion on this mailing list if you have
> ideas for improvement.
>
> Benjamin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Benjamin Poulain]

On Fri, Apr 27, 2012 at 2:18 PM, Dirk Pranke  wrote:
> That said, what sort of "officialness" does this
> writeup/guideline/policy have? Do all the ports agree that this is
> what our stance should be?

Everyone seemed to agree we just need to discuss each deprecation on
webkit-dev with solid supporting data.

Feel free to continue the discussion on this mailing list if you have
ideas for improvement.

Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Deprecating features guideline wiki

[Dirk Pranke]

Hi Julien,

Thanks for the writeup! I definitely wanted to be in that discussion
but it conflicted with another discussion I wanted to be in. It looks
like I more or less agree with the writeup, though :).

That said, what sort of "officialness" does this
writeup/guideline/policy have? Do all the ports agree that this is
what our stance should be?

Also, presumably this only applies to features that have shipped on by
default in some ports?

-- Dirk

On Wed, Apr 25, 2012 at 10:14 AM, Julien Chaffraix
 wrote:
> Hi WebKittens,
>
> following the talk about "Deprecating (web-facing) features and vendor
> prefixing" [1], we decided to create a guideline covering new
> deprecations or un-prefixing [2]. The rationale is that this will
> avoid a lot of the mistakes that we have made in the previous
> deprecations and that wisdom could help newcomers understand the pain
> points.
>
> The current page is a draft compiled from the meeting notes so any
> discussions or editions are welcome!
>
> Thanks,
> Julien
>
> [1] 
> http://trac.webkit.org/wiki/Deprecating%20features%20and%20vendor%20prefixes
> [2] https://trac.webkit.org/wiki/DeprecatingFeatures
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set

[Tom Penzer]

OK, I've re-worked my proposal a bit from the feedback I've received,  
and I'll submit to w3.org public-html-comments. Here's my revised  
proposal:


Seeking feedback for my (hopefully relatively painless in practice  
compared to the alternatives - i.e. -webkit-image-set and html5  
) proposal to solve the problem of 2x-res (double-resolution)  
images with our current HTML and CSS standards for devices with high- 
resolution displays, such as 3rd Generation iPads and 4th generation  
iPhones and newer.


We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in  
the format {'scaling factor', 'scaling filename key'}, where the  
filename key is the often-standardized string added to the filename  
for 2x assets, i.e. '_2x' (it might even be possible to specify a  
different filename extension for the 2x asset by detecting whether the  
'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub- 
attributes to the 'image-scaling' attribute would include the optional  
boolean (defaulted to 'true') attribute 'assume-present', and  
potentially the optional attribute 'image-scaling-path' for cases  
where sites store their various scaled image assets in different  
directories than their 1x images.


2) A new series of optional attributes to the img tag named after the  
scaling factor, i.e. '2x', '4x', etc., (possible values include  
'true', 'false', a string for the double-res filename key, or 'url()'  
to specify a completely different path for the asset corresponding to  
that scaling factor)


3) A series of new optional CSS properties named after the scaling  
factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style- 
image-2x' (possible values for these include 'true', 'false', a string  
for the double-res filename key, or 'url()').


A simple example usage of these new capabilities would be the following:



The effect of adding this single line to the page would be that a user  
agent that wishes to display double-res images would then attempt to  
access 'filename_2x.ext' whenever it encounters an img tag like 'url=("filename.ext") />', or a CSS property like '.class {background- 
image: url("filename.ext");}', '.class {border-image:  
url("filename.ext");}' or '.class {list-style-image:  
url("filename.ext");}'. For all these, in the case that the  
'filename_2x.ext' file does not exist, a second request is made for  
'filename.ext'.


If the bulk of the 2x-resolution images are located in a different  
directory than the 1x assets, the meta tag could be extended as such:




Then, any 2x img or css-image assets would be requested from  
'2x_images/filename_2x.ext' instead of 'images/filename.ext'.


If a particular 2x img tag asset or css-image asset has a '@2x' double- 
resolution filename key instead of '_2x' for some reason (maybe you're  
integrating with some 3rd party off-site content with a different 2x  
naming convention), you could add a '2x' attribute to its img tag,  
such as '', or to its css properties, such as '.class  
{background-image-2x: "@2x";}'.


If a particular 2x-resolution img tag asset or css-image asset is not  
located in the same directory as the 1x asset, or if the filenames and/ 
or file formats are not identical to the 1x asset, a separate path  
could be specified by doing this: 'filena...@2x.ext") />', or to its css properties by doing: '.class  
{background-image-2x: url("path/to/filena...@2x.ext");}'.


In the case that a majority, but not all img and css-image assets are  
available in 2x resolution, the img assets that lack a 2x version  
would include the a tag such as, ', or a css property  
such as '.class{background-image-2x: false;}'.


In the case that a majority, but not all img and css-image assets are  
unavailable in 2x resolution, you would add the 'assume- 
present="{2,false}' attribute to the meta 'image-scaling' attribute,  
such as '>', and use the '2x' attribute to flag img assets with a double- 
resolution asset available, such as ', and the css with  
'.class {background-image-2x: true;}'.


In the case that no double-resolution image assets are available, the  
meta 'image-scaling' attribute can be simply omitted.


By using this approach, we avoid the need to specify the same list of  
filenames varying only by scaling factor filename key for every single  
image asset, which is a bunch of busy work that just seems extremely  
redundant and clumsy to me. We are also able to achieve the same level  
of performance for those willing to put in the extra work to flag  
assets that deviate from the default setting (to minimize requests),  
and we allow the flexibility to be lazy or wrong, and have the user  
agent make two requests in those cases. This solution is also  
completely backwards-compatible with existing browsers. We can revisit  
whether or not this was really the best approach once 4x displays are  
out, but it's going to save millions of collective developer-h

Re: [webkit-dev] Implementing CSS3 Paged Media Margin Boxes

[Eric Seidel]

Ref-tests did not exist in WebKit when I last looked at this.  I added
pdf printing tests, only to realize that pdfs include user/machine
information and thus are useless for x-machine testing.

If our ref-test mechanism works for large pages that could work well.
:)  With printing tests you'll want to be able to test taht page 27
has the right number and that it was laid out on the 4th printed page,
etc. :)

On Fri, Apr 27, 2012 at 10:29 AM, Milian Wolff  wrote:
> On Friday 27 April 2012 10:08:13 Eric Seidel wrote:
>> When I last looked at the page media stuff (long ago).  The problem
>> was mostly going to be testing.  We don't have a good way to do
>> printing tests right now in WebKit.
>
> Someone in the webkit community introduced me to the idea of reftests, which
> seem to be a viable option for proper printing tests. I think of something
> like the following that should work since we know the pixel dimensions of a
> printed page in our unit tests to be 800x600:
>
> // @page margin test
> 
> 
> 
> * { margin:0; padding:0; }
> @page { margin: 10px; }
> div {  width: 800px; height: 600px; background: green; }
> 
> 
> 
> should have a 10px margin
> 
> 
> 
>
> // alternative
> 
> 
> 
> * { margin:0; padding:0; }
> div { width: 780px; height: 580px; margin: 10px; }
> 
> 
> 
> should have a 10px margin
> 
> 
> 
>
> Now both versions can be "printed" to PNG similar to what the existing
> LayoutTestController.setPrinting() does. The resulting two platform specific
> images can be compared and should match - if not, something went wrong.
>
> Am I missing something, is the above impractical?
>
> Cheers
>
>> On Fri, Apr 27, 2012 at 7:22 AM, Milian Wolff  wrote:
>> > Hey all,
>> >
>> > I would like to work on the CSS3 Paged Media support, esp. the margin
>> > boxes. I'm studying the code for some time now and would welcome it if
>> > someone could assist me in figuring out what needs to be done...
>> >
>> > First up, I think I should tackle the missing support in the parser, i.e.
>> > solving the FIXME in CSSParser::createMarginAtRule. I found that
>> > CSSFontFaceRule looks similar and could write some code based on that. A
>> > few questions arise now:
>> >
>> > a) For the unit tests (probably not only there) I need to have a special
>> > margin-at CSSRule for cssText(). I'll probably be able to copy most of the
>> > stuff again, but where in the build system do I have to add these new
>> > files?
>> >
>> > b) What CSSRule::Type should the above have? WEBKIT_MARGINAT_RULE at the
>> > end (hence value 11)?. I could not find an official IDL proposal that
>> > includes the margin at rules.
>> >
>> > c) These margin-at rules can only occur inside a page rule, and I need to
>> > access them from somewhere - what is the suggested path to take here?
>> > create StyleRulePage::setMarginRules or similar? Or reuse stuff from
>> > StyleRuleBlock?
>> >
>> > d) When I have some partial patch ready, where could I get input? Should I
>> > attach it to a bug report (I've opened
>> > https://bugs.webkit.org/show_bug.cgi?id=85062 for that purpose)
>> >
>> > f) I see that there are files like JSCSSFontFaceRuleCustom.cpp - what do I
>> > need to do there to get the new MediaAtRule accessible from JavaScript?
>> >
>> > Bye
>> > --
>> > Milian Wolff | milian.wo...@kdab.com | Software Engineer
>> > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
>> > Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
>> > KDAB - Qt Experts - Platform-independent software solutions
>> >
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> --
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing CSS3 Paged Media Margin Boxes

[Milian Wolff]

On Friday 27 April 2012 10:08:13 Eric Seidel wrote:
> When I last looked at the page media stuff (long ago).  The problem
> was mostly going to be testing.  We don't have a good way to do
> printing tests right now in WebKit.

Someone in the webkit community introduced me to the idea of reftests, which 
seem to be a viable option for proper printing tests. I think of something 
like the following that should work since we know the pixel dimensions of a 
printed page in our unit tests to be 800x600:

// @page margin test



* { margin:0; padding:0; }
@page { margin: 10px; }
div {  width: 800px; height: 600px; background: green; }



should have a 10px margin




// alternative



* { margin:0; padding:0; }
div { width: 780px; height: 580px; margin: 10px; }



should have a 10px margin




Now both versions can be "printed" to PNG similar to what the existing 
LayoutTestController.setPrinting() does. The resulting two platform specific 
images can be compared and should match - if not, something went wrong.

Am I missing something, is the above impractical?

Cheers

> On Fri, Apr 27, 2012 at 7:22 AM, Milian Wolff  wrote:
> > Hey all,
> > 
> > I would like to work on the CSS3 Paged Media support, esp. the margin
> > boxes. I'm studying the code for some time now and would welcome it if
> > someone could assist me in figuring out what needs to be done...
> > 
> > First up, I think I should tackle the missing support in the parser, i.e.
> > solving the FIXME in CSSParser::createMarginAtRule. I found that
> > CSSFontFaceRule looks similar and could write some code based on that. A
> > few questions arise now:
> > 
> > a) For the unit tests (probably not only there) I need to have a special
> > margin-at CSSRule for cssText(). I'll probably be able to copy most of the
> > stuff again, but where in the build system do I have to add these new
> > files?
> > 
> > b) What CSSRule::Type should the above have? WEBKIT_MARGINAT_RULE at the
> > end (hence value 11)?. I could not find an official IDL proposal that
> > includes the margin at rules.
> > 
> > c) These margin-at rules can only occur inside a page rule, and I need to
> > access them from somewhere - what is the suggested path to take here?
> > create StyleRulePage::setMarginRules or similar? Or reuse stuff from
> > StyleRuleBlock?
> > 
> > d) When I have some partial patch ready, where could I get input? Should I
> > attach it to a bug report (I've opened
> > https://bugs.webkit.org/show_bug.cgi?id=85062 for that purpose)
> > 
> > f) I see that there are files like JSCSSFontFaceRuleCustom.cpp - what do I
> > need to do there to get the new MediaAtRule accessible from JavaScript?
> > 
> > Bye
> > --
> > Milian Wolff | milian.wo...@kdab.com | Software Engineer
> > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> > Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> > KDAB - Qt Experts - Platform-independent software solutions
> > 
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing CSS3 Paged Media Margin Boxes

[Eric Seidel]

When I last looked at the page media stuff (long ago).  The problem
was mostly going to be testing.  We don't have a good way to do
printing tests right now in WebKit.

On Fri, Apr 27, 2012 at 7:22 AM, Milian Wolff  wrote:
> Hey all,
>
> I would like to work on the CSS3 Paged Media support, esp. the margin boxes.
> I'm studying the code for some time now and would welcome it if someone could
> assist me in figuring out what needs to be done...
>
> First up, I think I should tackle the missing support in the parser, i.e.
> solving the FIXME in CSSParser::createMarginAtRule. I found that
> CSSFontFaceRule looks similar and could write some code based on that. A few
> questions arise now:
>
> a) For the unit tests (probably not only there) I need to have a special
> margin-at CSSRule for cssText(). I'll probably be able to copy most of the
> stuff again, but where in the build system do I have to add these new files?
>
> b) What CSSRule::Type should the above have? WEBKIT_MARGINAT_RULE at the end
> (hence value 11)?. I could not find an official IDL proposal that includes the
> margin at rules.
>
> c) These margin-at rules can only occur inside a page rule, and I need to
> access them from somewhere - what is the suggested path to take here? create
> StyleRulePage::setMarginRules or similar? Or reuse stuff from StyleRuleBlock?
>
> d) When I have some partial patch ready, where could I get input? Should I
> attach it to a bug report (I've opened
> https://bugs.webkit.org/show_bug.cgi?id=85062 for that purpose)
>
> f) I see that there are files like JSCSSFontFaceRuleCustom.cpp - what do I
> need to do there to get the new MediaAtRule accessible from JavaScript?
>
> Bye
> --
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Implementing CSS3 Paged Media Margin Boxes

[Milian Wolff]

Hey all,

I would like to work on the CSS3 Paged Media support, esp. the margin boxes. 
I'm studying the code for some time now and would welcome it if someone could 
assist me in figuring out what needs to be done...

First up, I think I should tackle the missing support in the parser, i.e. 
solving the FIXME in CSSParser::createMarginAtRule. I found that 
CSSFontFaceRule looks similar and could write some code based on that. A few 
questions arise now:

a) For the unit tests (probably not only there) I need to have a special 
margin-at CSSRule for cssText(). I'll probably be able to copy most of the 
stuff again, but where in the build system do I have to add these new files?

b) What CSSRule::Type should the above have? WEBKIT_MARGINAT_RULE at the end 
(hence value 11)?. I could not find an official IDL proposal that includes the 
margin at rules.

c) These margin-at rules can only occur inside a page rule, and I need to 
access them from somewhere - what is the suggested path to take here? create 
StyleRulePage::setMarginRules or similar? Or reuse stuff from StyleRuleBlock?

d) When I have some partial patch ready, where could I get input? Should I 
attach it to a bug report (I've opened 
https://bugs.webkit.org/show_bug.cgi?id=85062 for that purpose)

f) I see that there are files like JSCSSFontFaceRuleCustom.cpp - what do I 
need to do there to get the new MediaAtRule accessible from JavaScript?

Bye
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] CSS3 Paged Media Support - Status Quo?

[Milian Wolff]

Hey there,

I'd like to know what part of the CSS3 paged media module is currently 
implemented in WebKit.

I see that the parser can handle most of it, yet at least margin boxes need 
some work.

But when it comes to actually handling these properties - has there been any 
work on this yet? There are tests like printing/page-rule-in-media-query.html 
that use page margins, but I think it does not actually test whether it is 
properly applied.

Grepping in the sources, I don't see any usage of Document::styleForPage 
anywhere outside of "code for tests" - is this correct? Is none of these 
things actually handled so far?

If there are parts of it implemented somewhere (maybe just for specific 
ports), could someone please point me into the correct directions?

Bye
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev