Re: [webkit-dev] Implementing style scoped
On Wed, Sep 14, 2011 at 1:26 AM, Roland Steiner rolandstei...@google.comwrote: On Mon, Sep 12, 2011 at 4:21 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Yeah. You're right. We should get Hixie to change the spec. I don't think we should implement currently spec'd behavior or change the name. That last option sounds exceptionally bad. Roland, can you post on that thread and request the spec change? Posted. :) In those threads it seems we arrived at a preliminary agreement: On Wed, Sep 28, 2011 at 2:49 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Roland Steiner wrote: Hm, AFAICT Hixie's mail on www-style@ didn't raise any objections against the idea [of scoped selectors] itself, the discussion just revolves around what the exact syntax should be. Given that, what is the chance that we are able to go forward and declare selectors within style scoped as scoped, and leave the question how such selectors can breach the scoping as an orthogonal problem? Go for it. I recommend going with [@global] for now, too. Unless a better proposal gets put forward, I'll spec it in the near future. (So far nothing better has been put forward.) In this light, are there any remaining objections to implement this with 'scoped' as the attribute name? Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Making top-level style changes through window.internals
Hi all, pageScaleFactor is a document level CSS scaling style. Often times, we'd like to be able to apply style at the document level when writing layout tests. As far as I'm aware, there's no way to do this in javascript in a layout test? Is this correct? If so, would anyone object to exposing document-level styles to window.internals? If not there, is there anywhere else where this can be exposed for testing purposes? Thanks, Fady Samuel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making top-level style changes through window.internals
On Sep 29, 2011, at 11:37 AM, Fady Samuel wrote: pageScaleFactor is a document level CSS scaling style. Often times, we'd like to be able to apply style at the document level when writing layout tests. As far as I'm aware, there's no way to do this in javascript in a layout test? Is this correct? If so, would anyone object to exposing document-level styles to window.internals? If not there, is there anywhere else where this can be exposed for testing purposes? In the particular case of pageScaleFactor I believe we already have eventSender.scalePageBy. (I think it's on eventSender rather than layoutTestController because it was first used to simulate Safari's pinch-to-zoom feature.) Moving this feature to window.internals and adding other similar features seems fine to me. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making top-level style changes through window.internals
On Sep 29, 2011, at 8:41 AM, Adam Roben wrote: On Sep 29, 2011, at 11:37 AM, Fady Samuel wrote: pageScaleFactor is a document level CSS scaling style. Often times, we'd like to be able to apply style at the document level when writing layout tests. As far as I'm aware, there's no way to do this in javascript in a layout test? Is this correct? If so, would anyone object to exposing document-level styles to window.internals? If not there, is there anywhere else where this can be exposed for testing purposes? In the particular case of pageScaleFactor I believe we already have eventSender.scalePageBy. (I think it's on eventSender rather than layoutTestController because it was first used to simulate Safari's pinch-to-zoom feature.) Moving this feature to window.internals and adding other similar features seems fine to me. Agreed. Fady, in what other instances do you need to change document-level style? Don't forget that it's possible to change style on the 'html' element (which is the document element) via document.documentElement.style.foo =... Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making top-level style changes through window.internals
All of this discussion started with my wanting to write a layout test that changes pageScaleFactor, without incurring scroll bars in the process. The documentElement.style method below seems to be able to change, for example, background colour, but it doesn't seem to work for documentElement.style.overflow = hidden. Is there somewhere else the scroll bars should be suppressed? On Thu, Sep 29, 2011 at 11:44 AM, Simon Fraser simon.fra...@apple.comwrote: On Sep 29, 2011, at 8:41 AM, Adam Roben wrote: On Sep 29, 2011, at 11:37 AM, Fady Samuel wrote: pageScaleFactor is a document level CSS scaling style. Often times, we'd like to be able to apply style at the document level when writing layout tests. As far as I'm aware, there's no way to do this in javascript in a layout test? Is this correct? If so, would anyone object to exposing document-level styles to window.internals? If not there, is there anywhere else where this can be exposed for testing purposes? In the particular case of pageScaleFactor I believe we already have eventSender.scalePageBy. (I think it's on eventSender rather than layoutTestController because it was first used to simulate Safari's pinch-to-zoom feature.) Moving this feature to window.internals and adding other similar features seems fine to me. Agreed. Fady, in what other instances do you need to change document-level style? Don't forget that it's possible to change style on the 'html' element (which is the document element) via document.documentElement.style.foo =... Simon ___ 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] Compile-time assertions for object sizes
Dear WebKittens, I'd like to add some compile-time assertions for the sizes of various objects. The motivation comes a patch fixing bloat in InlineBox[1]. There are two major problems with this: 1. The sizes will differ on 32- and 64-bit platforms. 2. The sizes will differ based on compiler flags. One idea is to add a file that would only be built on (for example) 64-bit Mac and then at least that bot would break if an object changes size. That's obviously not ideal though. Any suggestions? :) -Kling [1] https://bugs.webkit.org/show_bug.cgi?id=64914 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Thu, Sep 29, 2011 at 12:11 PM, Simon Fraser simon.fra...@apple.comwrote:
On Sep 29, 2011, at 11:40 AM, Andreas Kling wrote:
Dear WebKittens,
I'd like to add some compile-time assertions for the sizes of various
objects. The motivation comes a patch fixing bloat in InlineBox[1].
There are two major problems with this:
1. The sizes will differ on 32- and 64-bit platforms.
2. The sizes will differ based on compiler flags.
One idea is to add a file that would only be built on (for example)
64-bit Mac and then at least that bot would break if an object changes size.
That's obviously not ideal though.
Any suggestions? :)
You could group the bits together into a struct:
struct {
m_foo: 1;
m_bar: 1;
...
} m_bits;
COMPILE_ASSERT(sizeof(m_bits) = sizeof(uint32_t), Too_many_bits);
This wouldn't' be sensitive to architecture.
Simon
Perhaps you'll find some inspiration in
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/SizeLimits.cppwhere
this is done for a few structs in wtf.
I tried to use sizeof(int*) where I needed to deal with 32 vs 64 pointer
issues and I put in an ifdef for a debug related size thing.
dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Sep 29, 2011, at 11:40 AM, Andreas Kling wrote:
Dear WebKittens,
I'd like to add some compile-time assertions for the sizes of various
objects. The motivation comes a patch fixing bloat in InlineBox[1].
There are two major problems with this:
1. The sizes will differ on 32- and 64-bit platforms.
2. The sizes will differ based on compiler flags.
One idea is to add a file that would only be built on (for example) 64-bit
Mac and then at least that bot would break if an object changes size. That's
obviously not ideal though.
Any suggestions? :)
You could group the bits together into a struct:
struct {
m_foo: 1;
m_bar: 1;
...
} m_bits;
COMPILE_ASSERT(sizeof(m_bits) = sizeof(uint32_t), Too_many_bits);
This wouldn't' be sensitive to architecture.
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Thu, Sep 29, 2011 at 9:11 PM, Simon Fraser simon.fra...@apple.comwrote:
On Sep 29, 2011, at 11:40 AM, Andreas Kling wrote:
Dear WebKittens,
I'd like to add some compile-time assertions for the sizes of various
objects. The motivation comes a patch fixing bloat in InlineBox[1].
There are two major problems with this:
1. The sizes will differ on 32- and 64-bit platforms.
2. The sizes will differ based on compiler flags.
One idea is to add a file that would only be built on (for example)
64-bit Mac and then at least that bot would break if an object changes size.
That's obviously not ideal though.
Any suggestions? :)
You could group the bits together into a struct:
struct {
m_foo: 1;
m_bar: 1;
...
} m_bits;
COMPILE_ASSERT(sizeof(m_bits) = sizeof(uint32_t), Too_many_bits);
This wouldn't' be sensitive to architecture.
Good idea in general, though it doesn't work for InlineBox since its bits
are spread across public, protected and private.
I'm not sure it's worth losing those classifications for the sake of the
anti-bloat mechanism.
-Kling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Sep 29, 2011, at 1:40 PM, Andreas Kling wrote: Good idea in general, though it doesn't work for InlineBox since its bits are spread across public, protected and private. I'm not sure it's worth losing those classifications for the sake of the anti-bloat mechanism. We wouldn’t have to lose those classifications. We’d just have to lose our convention that all public are grouped together, etc. We can intersperse public/protected/private keywords between bitfield definitions. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Thu, Sep 29, 2011 at 10:43 PM, Darin Adler da...@apple.com wrote: On Sep 29, 2011, at 1:40 PM, Andreas Kling wrote: Good idea in general, though it doesn't work for InlineBox since its bits are spread across public, protected and private. I'm not sure it's worth losing those classifications for the sake of the anti-bloat mechanism. We wouldn’t have to lose those classifications. We’d just have to lose our convention that all public are grouped together, etc. We can intersperse public/protected/private keywords between bitfield definitions. Right, but those keywords would pertain to the struct containing the bitfields, not InlineBox itself. Or maybe I'm misunderstanding you? -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Sep 29, 2011, at 1:48 PM, Andreas Kling wrote: Right, but those keywords would pertain to the struct containing the bitfields, not InlineBox itself. Or maybe I'm misunderstanding you? Yes, I was wrong, you are right. I had lost the thread. I’m not sure we need to group bit fields in a struct. I think it is practical to write the size assertions in a way that works both in 32- and 64-bit. David Levin found some good techniques that he used in SizeLimits.cpp. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compile-time assertions for object sizes
On Thu, Sep 29, 2011 at 9:40 PM, Andreas Kling kl...@webkit.org wrote: One idea is to add a file that would only be built on (for example) 64-bit Mac and then at least that bot would break if an object changes size. That's obviously not ideal though. I like that approach as it allows you to explicitly assert against byte counts. Other approaches are more abstract and so easier to dismiss when checking in a bloaty patch. It also documents the byte sizes and makes progressions explicit too. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XCode 4.0
HIApologies in advance for this newbie question.I started to have a deeper look into WebKit code for some bugs I would like to fix . In order to grasp the develop/compile/debug cycle for webkit, I did follow the instructions athttps://ebkit.org/building/debug.htmlHowever it looks like Xcode 4.0 is far form what is written.Are there any guidelines for Xcode 4.1 (or above)? Or is using directly db in the console the favored way to proceed?thankslaurent___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XCode 4.0
I know some people have been building WebKit with the 4.1 IDE, but after a cursory attempt I was only able to build from the command line. I'd also love tips from those more familiar with it :) -Levi On Thu, Sep 29, 2011 at 3:04 PM, lcerveau lcerv...@me.com wrote: HI Apologies in advance for this newbie question. I started to have a deeper look into WebKit code for some bugs I would like to fix . In order to grasp the develop/compile/debug cycle for webkit, I did follow the instructions at https://ebkit.org/building/debug.html However it looks like Xcode 4.0 is far form what is written. Are there any guidelines for Xcode 4.1 (or above)? Or is using directly db in the console the favored way to proceed? thanks laurent ___ 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
