Re: [webkit-dev] Intent to implement in Blink: CSS properties break-{after, before, inside}
https://bugs.webkit.org/attachment.cgi?id=270221&action=review > On Jan 21, 2016, at 8:35 AM, Morten Stenshorne wrote: > > Thanks for your quick response! > > David Hyatt writes: > >> We are in favor of those properties. If you want to talk about “avoid” >> specifically offline, I outlined a plan for implementing that property >> in one of the webkit bugs (I’ll have to hunt down the link). I think >> it basically needs to work a bit like margin collapsing in the sense >> that you need to propagate out knowledge of the break intent at the >> top and bottom of blocks, and then “collapse” with adjacent blocks to >> determine what the break intent should be at a given position. >> >> dave >> >>> On Jan 19, 2016, at 1:12 PM, Morten Stenshorne wrote: >>> >>> Hello WebKit! :) >>> >>> I'm planning to implement the CSS properties break-after, break-before >>> and break-inside [1] in Blink. As part of that process, I need to ask >>> other browser vendors about their views / plans regarding this web >>> platform feature. I'd especially like to know if you have anything >>> against implementing these properties (apart from priorities). >>> >>> Thanks in advance! >>> >>> [1] https://www.chromestatus.com/feature/5630943616303104 >>> >>> -- >>> Morten Stenshorne, developer, Opera Software ASA >>> -- http://www.opera.com/ - >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> > > -- > Morten Stenshorne, developer, Opera Software ASA > -- http://www.opera.com/ - ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Intent to implement in Blink: CSS properties break-{after, before, inside}
We are in favor of those properties. If you want to talk about “avoid” specifically offline, I outlined a plan for implementing that property in one of the webkit bugs (I’ll have to hunt down the link). I think it basically needs to work a bit like margin collapsing in the sense that you need to propagate out knowledge of the break intent at the top and bottom of blocks, and then “collapse” with adjacent blocks to determine what the break intent should be at a given position. dave > On Jan 19, 2016, at 1:12 PM, Morten Stenshorne wrote: > > Hello WebKit! :) > > I'm planning to implement the CSS properties break-after, break-before > and break-inside [1] in Blink. As part of that process, I need to ask > other browser vendors about their views / plans regarding this web > platform feature. I'd especially like to know if you have anything > against implementing these properties (apart from priorities). > > Thanks in advance! > > [1] https://www.chromestatus.com/feature/5630943616303104 > > -- > Morten Stenshorne, developer, Opera Software ASA > -- http://www.opera.com/ - > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Zoltan Horvath is now a WebKit reviewer
Hi all, I'm pleased to announce that you now have someone new to pester for layout and rendering patch reviews! Zoltan Horvath is now a WebKit reviewer. He has done some excellent work in layout and rendering. He has primarily worked on shapes code, but also did useful refactoring in areas like line layout. Congratulations, Zoltan! dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement ruby-overhang
On Apr 17, 2013, at 2:26 AM, Yuki Sekiguchi wrote: > Hi, > > I'd like to add support for ruby-overhang. > The spec for this feature can be found here: > http://www.w3.org/TR/css3-ruby/#rubyover > > I'm working it at this bug > https://bugs.webkit.org/show_bug.cgi?id=114678 > > My concern is that this patch changes the default behavior of > overhanging ruby text. > CSS spec says that initial value is "none", but current behavior is like > "auto". I believe auto is a better initial value than none. We should make the initial value auto for now and try to get the spec changed. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
I agree with you that this would be pretty terrible. We definitely don't want developers doing that. dave On Feb 28, 2013, at 8:02 PM, Adam Barth wrote: > I noticed this comment on the Hacker News thread about Paul Irish's > recent blog post: > > ---8<--- > "CSS parsing is the same, though. Slurping up your CSS and turning it > into CSSOM’s pretty standard. Yeah, though Chrome accepts just the > -webkit- prefix whereas Apple and other ports accept legacy prefixes > like -khtml- and -apple-." > > Using this information, can you target Chrome with the webkit- prefix > and Safari with the apple- prefix? Specifying the apple- prefix after > webkit- will ensure that Safari uses that one, right? > --->8--- > > http://news.ycombinator.com/item?id=5302150 > > If developers start using this technique, it might be harder to remove > these prefixes in the future. Chromium's experience removing these > prefixes has been quite positive. We ran into one compatibility > problem on apple.com, which Apple was gracious enough to fix. > > I'd recommend that the rest of the ports disable > ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- > and -apple- CSS prefixes before it's too late. > > Adam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should focus ring include out-of-flow sub-elements?
Excluding out of flow descendants would cause compatibility issues. You cannot always exclude them. If you want to discuss how better to handle the case where you end up with non-overlapping outline rings or outline rings with a lot of blank space, then I would suggest filing a bug on that specifically and having a discussion there. You can't just always exclude out of flow sub-elements or something as basic as: Hello (which happens all the time) doesn't work. It's quite common for the outline to originate on an object that doesn't itself paint anything but has out-of-flow descendants that do. dave (hy...@apple.com) On Feb 27, 2013, at 3:27 PM, Xianzhu Wang wrote: > The question is a bit out of the scope of the bug. It is related to how we > understand the standards about focus ring and outline. > Some comments of the bug also suggested to discuss in mailing list. > > I should have mentioned the reason of raising the question here at first :) > > > On Wed, Feb 27, 2013 at 1:12 PM, David Hyatt wrote: > Why can't this discussion just happen in the bug? > > dave > > On Feb 27, 2013, at 2:31 PM, Xianzhu Wang wrote: > >> Hi, >> >> The question was raised when I was trying to reduce the test case and fix >> wkbug.com/110895. >> >> Consider the following case (we use 'auto' outline style to draw focus >> rings): >> >> >> >> The outline will be like: >> _ >> | | >> |_| >> >> || >> Things would be more complex (and the visual effect would looks to me more >> weird) if we want to draw exact focus ring when the sub-layer is transformed. >> >> CSS2 (http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines) and CSS3 >> (http://dev.w3.org/csswg/css3-ui/#outline) describe outline similarly: >> >> Outlines may be non-rectangular. For example, if the element is broken >> across several lines, the outline should be an outline or minimum set of >> outlines that encloses all the element's boxes. >> >> However, CSS3 also mentions: >> >> User agents should use an algorithm for determining the outline that >> encloses a region appropriate for conveying the concept of focus to the user. >> >> IMHO, the focus ring shown above couldn't convey the concept of focus well >> to the user but seems to confuse the user. In addition, I believe sometimes >> the web page designer doesn't actually want an out-of-flow element to be a >> visual part of the ancestor elements. >> >> Tested Firefox19 and IE9 about the behavior. They don't support 'auto' >> outline style that WebKit uses to draw focus rings. I tested with 'solid' >> style and real focus rings. Firefox draws a single rectangle enclosing the >> element and all sub-elements. IE draws outline/focus ring around the element >> itself not enclosing sub-elements. (Actually IE's behavior is the same as >> WebKit's when outline-style!='auto' -- WebKit draws normal outlines >> differently from focus rings). >> >> I feel that things would be simpler (several bugs would be automatically >> fixed) and also clearer to the user/designer by excluding out-of-flow >> sub-elements when drawing focus rings. What are your opinions? >> >> Thanks, >> Xianzhu >> >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should focus ring include out-of-flow sub-elements?
Why can't this discussion just happen in the bug? dave On Feb 27, 2013, at 2:31 PM, Xianzhu Wang wrote: > Hi, > > The question was raised when I was trying to reduce the test case and fix > wkbug.com/110895. > > Consider the following case (we use 'auto' outline style to draw focus rings): > > > > The outline will be like: > _ > | | > |_| > > || > Things would be more complex (and the visual effect would looks to me more > weird) if we want to draw exact focus ring when the sub-layer is transformed. > > CSS2 (http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines) and CSS3 > (http://dev.w3.org/csswg/css3-ui/#outline) describe outline similarly: > > Outlines may be non-rectangular. For example, if the element is broken across > several lines, the outline should be an outline or minimum set of outlines > that encloses all the element's boxes. > > However, CSS3 also mentions: > > User agents should use an algorithm for determining the outline that encloses > a region appropriate for conveying the concept of focus to the user. > > IMHO, the focus ring shown above couldn't convey the concept of focus well to > the user but seems to confuse the user. In addition, I believe sometimes the > web page designer doesn't actually want an out-of-flow element to be a visual > part of the ancestor elements. > > Tested Firefox19 and IE9 about the behavior. They don't support 'auto' > outline style that WebKit uses to draw focus rings. I tested with 'solid' > style and real focus rings. Firefox draws a single rectangle enclosing the > element and all sub-elements. IE draws outline/focus ring around the element > itself not enclosing sub-elements. (Actually IE's behavior is the same as > WebKit's when outline-style!='auto' -- WebKit draws normal outlines > differently from focus rings). > > I feel that things would be simpler (several bugs would be automatically > fixed) and also clearer to the user/designer by excluding out-of-flow > sub-elements when drawing focus rings. What are your opinions? > > Thanks, > Xianzhu > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS Masking in WebKit
This is great! I'd like to be the goto reviewer for any changes you make on the CSS Masking side, since I implemented the original code. I also want to be kept in the loop if any changes are made to the way any of the -webkit-mask-* properties are specified. There are some interesting differences (especially in default values) when compared with the corresponding background/border-image properties, and I want to make sure all of that is well understood. Also, it's important to make sure if there are any deviations/changes, that the -webkit-prefixed versions of these properties don't change behavior. Backwards compatibility is extremely important here. You'll notice that the way I preserved backwards compatibility on border-image for example was to go ahead and implement the unprefixed versions. I don't really have a good suggestion for how to do that here... it's possible a new prefix will be necessary. It all depends on if any changes are made that would break existing code. dave (hy...@apple.com) On Aug 29, 2012, at 5:41 PM, Dirk Schulze wrote: > Hi WebKit folks, > > The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. > Basically the spec aims to specify the behavior of > -webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath > on Firefox. > > I would like to implement the specification in the next weeks and months. > Since masking and clipping are basic operations that use the existing > capabilities in all graphic libraries, and sine we are using it heavily > internally in WebKit already, I do not plan to introduce a new compiler flag. > > However, some features will be covered by existing compiler flags like SVG > Mask and SVG ClipPath, allowing to disable these parts. > > I created a master bug that covers the work [2]. > > Greetings, > Dirk > > [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html > [2] https://bugs.webkit.org/show_bug.cgi?id=95389 > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the New XMLParser dead?
On Aug 27, 2012, at 7:17 PM, Adam Barth wrote: > My position is simple: the code is broken and unused. As a general > rule, we shouldn't keep broken, unused code in the tree for extended > periods of time. Therefore, we should remove it. I agree with Adam. We should aggressively cull dead code from the tree. It's the only way to keep things tidy. "I may get back to it at some point in the future" is a fine statement, but without any firm commitment, it seems best to just remove the code from the tree for now. If and when someone steps up to actually work on it again, it shouldn't be much work to bring the code back to life. Forcing everyone else to deal with code that may or may not ever be returned to in the meantime isn't really fair to the rest of the project. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
On Aug 22, 2012, at 10:11 AM, Milian Wolff wrote: > On Monday 20 August 2012 11:15:21 David Hyatt wrote: >> You're going to see some patches in the coming weeks (first one coming soon) >> to begin work on implementing: >> >> http://www.w3.org/TR/css3-gcpm/ >> >> In some cases, there are going to be syntactic deviations from the spec as >> we experiment (based off discussions that are ongoing in the CSS WG), but >> in general we'll be implementing the features in the working draft. > > Hey there, > > very interesting to see you working on this! Can you tell me whether you are > going to work on the css3 paged-based media module next? Paired with GCPM it > would make WebKit a very powerful publishing tool. > > Thanks, take care. There are a number of tasks happening first that are mostly about fixing what code is there. Right now we have a screen pagination mode that works in terms of columns. This has led us to add CSS properties to hack how columns get stacked (inline direction or block direction), when in reality this pagination mode should be operating in terms of pages instead. In addition columns and pages don't play well together in terms of nesting. You can't even print a page with columns on it for example, because we're incapable of handling that nesting. So architecturally what's happening is that pages and columns are getting a complete re-write, and they're being re-implemented in terms of regions and flow threads. In effect, we're unifying columns, pages and CSS Regions to all work in terms of RenderFlowThreads that hold the actual content and RenderRegions that the content flows into. RenderRegion and RenderFlowThread are the base classes used by all three models. RenderRegionSet is a new class that derives from RenderRegion and represents a run of contiguous identical regions. It is going to be used by columns and pages and (assuming it gets adopted) by overflow:regions (dbaron's proposal for auto-cloning of new regions to accommodate overflow). RenderPageSet and RenderColumnSet derive from RenderRegionSet and handle specialized rendering of pages and column boxes. For example, RenderPageSet will eventually be expanded to render all the additional boxes around pages that CSS3 Paged Media allows. Columns will no longer have any code in RenderBlock. Everything will be in subclasses, i.e., RenderMultiColumnBlock. When printing, RenderView will shunt its children into a RenderPageFlowThread and create RenderPageSets as needed for the pages (with runs of identical pages sharing the same page set). The screen pagination mode that changes RenderView to have columns will be re-written to use a RenderPageFlowThread and RenderPageSet instead. RenderPageSet will know about progression direction and it will determine this based off overflow:paged-x/paged-y instead of having a custom column-specific property. Anyway, that's the basic run-down. There is a lot of architectural work to be done to build up this new model, but the advantage is that regions, pages and columns will all be nestable and work much better together (e.g., you'll be able to have columns thread through regions, or regions thread through pages, etc.). dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
On Aug 20, 2012, at 12:40 PM, Alan Stearns wrote: > On 8/20/12 10:07 AM, "David Hyatt" wrote: > >> On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote: >> >> >> Addendum: The current Editor's Draft is significant different from the >> published WD, and includes something similar to CSS Exclusions. Since >> Adobe is implementing these in WebKit, it may be good to know what your >> ideas on these are as >> well :-). >> http://dev.w3.org/csswg/css3-gcpm/ >> >> >> Thanks, >> Peter >> >> >> >> >> >> We're not touching the "controversial" stuff. :) >> >> >> Specifically we're looking into implementing the screen pagination mode >> (paged-x/paged-y overflow) and the associated features that come along >> with that. >> >> >> We're also going to implement page floats and the general improvements to >> multi-column layout that are in the draft. > > > Do the multi-column improvements you're considering include column > selectors? > Nope. I want to wait a bit and see if we get all the selector stuff reconciled with regions. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote: > Addendum: The current Editor's Draft is significant different from the > published WD, and includes something similar to CSS Exclusions. Since Adobe > is implementing these in WebKit, it may be good to know what your ideas on > these are as well :-). > http://dev.w3.org/csswg/css3-gcpm/ > > Thanks, > Peter We're not touching the "controversial" stuff. :) Specifically we're looking into implementing the screen pagination mode (paged-x/paged-y overflow) and the associated features that come along with that. We're also going to implement page floats and the general improvements to multi-column layout that are in the draft. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New feature: CSS3 GCPM
You're going to see some patches in the coming weeks (first one coming soon) to begin work on implementing: http://www.w3.org/TR/css3-gcpm/ In some cases, there are going to be syntactic deviations from the spec as we experiment (based off discussions that are ongoing in the CSS WG), but in general we'll be implementing the features in the working draft. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecation of CSSStyleDeclaration -> getPropertyShorthand method.
Yup, no reason for it to be exposed any more. It was just needed way back when
the Inspector used JS.
dave
(hy...@apple.com)
On May 21, 2012, at 2:39 PM, Alexis Menard wrote:
> On Mon, May 21, 2012 at 4:29 PM, Maciej Stachowiak wrote:
>>
>> On May 21, 2012, at 11:09 AM, Alexis Menard
>> wrote:
>>
>>> Hi,
>>>
>>> Let's try the new deprecation process documented as
>>> http://trac.webkit.org/wiki/DeprecatingFeatures.
>>>
>>> I would like to propose the deprecation and removal of
>>> getPropertyShorthand of CSSStyleDeclaration.
>>>
>>> State of art :
>>> - This method is exposed to the Web.
>>> - Its purpose is to get whether a given CSS property was set from
>>> within a shorthand (i.e.
>>> shouldBeEqualToString("test0.style.getPropertyShorthand('overflow-x')",
>>> "overflow"); is true if the CSS code is setting the overflow and not
>>> overflow-x).
>>> - It is used in 4 layout tests (fast/inspector-support/style.html,
>>> fast/css/font-shorthand.html, fast/css/overflow-property.html,
>>> fast/backgrounds/repeat/resources/background-repeat-shorthand.js)
>>> - It is exposed in the Objective C API.
>>> - It is not implemented by any other vendors (Opera, Firefox, Internet
>>> Explorer).
>>> - There is no specification about it.
>>> - It was added in 2005 http://trac.webkit.org/changeset/11481.
>>
>> [...]
>>
>>> This function was added by Dave Hyatt and reviewed by Maciej
>>> Stachowiak, maybe you guys can tell us why you added it back then (if
>>> your memory is very good as we are talking about 2005 material)?
>>
>> I don't know of any reason for this to exist other than for benefit of the
>> inspector. It appears to no longer be used by the Web Inspector, thought it
>> has its own function with the same name (assuming I am reading the code
>> right). It would be fine to stop exposing it to the web if it is in fact
>> unused or hardly used.
>
> I was looking at the code of the inspector and also assuming I'm
> reading the code right it is not used.
>
> The C++ method getPropertyShorthand seems to be used in
> InspectorStyleSheet.cpp which then is used in
> inspector/front-end/CSSStyleModel.js and its usage seems to be
> confined in styleTextWithShorthands which is not used anywhere (at at
> least grep says so).
>
> But Pavel and Vsevolod can confirm that.
>
>>
>> - Maciej
>>
>
>
>
> --
> Alexis Menard (darktears)
> Software Engineer
> openBossa @ INdT - Instituto Nokia de Tecnologia
> ___
> 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] paged media update?
The difficulty with implementing paged media right now is that I'm beginning work on re-architecting pagination to unify columns, pages and regions. You can see the beginnings of this with the new multi-column classes that have been added to the tree. The basic idea is that multi-column layout is being separated from RenderBlock and moved to a subclass, RenderMultiColumnBlock. Similar to how regions work, the content is represented by a flow thread and by regions that the flow thread is placed into. In order to avoid creating thousands of regions for columns, I've introduced the concept of a "region set", i.e., RenderMultiColumnSet. Pages ultimately need to be rebuilt to work the same way, i.e., to have a RenderPageFlowThread and a RenderPageSet. Once we have actual renderers that represent these objects, it will be a lot easier to make real boxes for things like margins, headers, footers, etc. The idea is that a set represents a contiguous run of objects that can all be rendered identically. If you're forced to have a different kind of object, e.g., a page with a different width/height or different style, then you break up the RenderPageSet and have multiple sets for each (this is similar to how regions work by default, although I hope to apply the same optimization to regions eventually as well if runs of same width/height regions are detected that are also siblings in the render tree). dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Handling failing reftests
That reftest is mine. It was supposed to work cross-platform. I am happy to fix, but I'd need to understand what about it didn't work on other platforms. Can someone send me a screenshot of what it looks like? (This is actually why I hate reftests for pagination. It's very hard to construct an unpaginated version that matches the paginated layout without tripping over stuff like this.) Thanks Dave (hy...@apple.com) On Apr 12, 2012, at 1:01 PM, Ryosuke Niwa wrote: > On Thu, Apr 12, 2012 at 10:57 AM, Dirk Pranke wrote: > This is an interesting situation; does it make sense to require our > reftests to be generic, or is that unrealistic? I also wonder if we > should allow platform-specific pixel tests to coexist with > platform-specific reference tests (since you could obviously write a > platform-specific ref test that just displayed a single IMG, but the > tools don't make that particularly easy). > > Allowing platform-specific pixel results for a ref test is a bad idea IMO. It > makes things even more complicated and harder to understand than it already > is today. > > - Ryosuke > > ___ > 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] Unit Test for Page Breaks / absolute coordinates in PrintContext::pageNumberForElement
Do you have a bug for this work? I'm not really sure what you're trying to accomplish… avoiding page breaks in a table row does not seem correct to me. dave On Mar 29, 2012, at 8:23 AM, Milian Wolff wrote: > Hey there, > > I'm trying to write a unit test for my layouting patch, that prevents page > breaks in table rows. So far, I've extended the layoutTestController with a > pageBreaksInElementById function, similar to pageNumberForElementById. > > The logic behind the implementation is basically an extended copy of > PrintContext::pageNumberForElement, see e.g. [1]. > > Now in my unit test, I call this function for every table row and "ensure" > that the return value is always 0, i.e. no page break. Turns out, that this > does not work as expected: My table layouting code [2] takes the offset of > the > surrounding table into account, and the visual result looks OK. The unit test > code ([1]) though apparently assumes absolute coordinates, which (I think?!) > box->pixelSnappedOffsetLeft() is *not*. What could be used instead? Also, > doesn't this also mean that the logic of PrintContext::pageNumberForElement > is > flawed for nested elements that are offsetted? > > Note btw. that the box does not have any layout state when called from > PrintContext::pageBreaksInElement, as such I cannot simply add a call to > RenderBlock::offsetFromLogicalTopOfFirstPage(). > > Thanks > > [1]: http://paste.kde.org/448514/ > [2]: http://paste.kde.org/448520/ > -- > 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] CSS3 Paged Media module
That page should be updated. We don't have that architectural flaw any longer since I re-wrote pagination last year. dave (hy...@apple.com) On Mar 7, 2012, at 8:27 AM, Seo Sanghyeon wrote: > 2012/3/7, Milian Wolff : >> Ping? Could someone be so kind as to answer my questions below? > > As the following page admits, WebKit's printing architecture has > "the big flaw" and in general inferior to Gecko and other engines. > I fear you may have to rework most of WebKit's printing code to do > what you want. > > http://www.webkit.org/projects/printing/ > > -- > Seo Sanghyeon > ___ > 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] CSS properties vs. their JS bindings on the style object
We shouldn't fragment WebKit engine behavior like that, especially when the feature is already being used to detect WebKit browsers (any WebKit-based browser would just be shooting itself in the foot by removing support for this). My vote would be to just spec it. If Trident and WebKit already do it, let's just spec it and then FF and Opera can implement it too. dave (hy...@apple.com) On Mar 1, 2012, at 2:07 PM, Erik Arvidsson wrote: > How about making this a compile time flag or runtime flag so that > Apple Dashboard and iOS can keep it but let other users of WebKit > disable it? > > erik > > > > > On Tue, Feb 28, 2012 at 22:23, Benjamin Poulain wrote: >> On Tue, Feb 28, 2012 at 9:48 PM, wrote: >>> Seriously, I'm not sure how to proceed on this. It does seem to be >>> outside the spec. >> >> Either update the spec or create a path to deprecate the "bug". >> >> Personally, this "feature" sounds like it could be useful for web >> developers so updating the spec might not be a bad idea. >> >> 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] Subpixel Layout Update
I had a question about the subpixel layout stuff. Right now RenderBlock is full of comments talking about switching to floats, .e.g., FIXME: Might need rounding once we switch to float, see https://bugs.webkit.org/show_bug.cgi?id=64021 FIXME: Change to use roughlyEquals when we move to float. Are these comments obsolete? If so, can we get that code cleaned up? dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New CSS property -webkit-control-text-overflow
I strongly disagree with the reasoning in that post. You say: "As an author, I would find it strange that upon focus of a text input the ellipsis would just disappear." I think it would be even stranger for the ellipsis not to disappear and to be editing a truncated version of the input field's value. What does that that even mean? I'd rather the author be surprised than the user! It seems like the options are: (1) Ignore text-overflow completely on text fields. Support a new property for the dynamic display of the full text when focused. (2) Honor text-overflow strictly on text fields. Support a new property for the dynamic display of the full text when focused. (3) Use text-overflow for the dynamic display of the full text when focused. To me (3) is clearly the most attractive choice. (1) would surprise authors by having text-overflow not work. (2) would surprise both authors and users by having text-overflow work badly when you focused the control. I see absolutely no reason to introduce a new property here, especially after hearing that Gecko just made text-overflow do this already. My expectation is that we would match Gecko's behavior and not introduce a new property. dave (hy...@apple.com) On Jan 16, 2012, at 1:53 PM, Jon Lee wrote: > There is a thread on the www-style list that discusses this point: > > http://lists.w3.org/Archives/Public/www-style/2012Jan/0687.html > > On Jan 16, 2012, at 11:41 AM, David Hyatt wrote: > >> I have the same question. Can you explain why text-overflow is insufficient? >> I think in this case it would be acceptable behavior to just make >> text-overflow behave the way you want, i.e., no longer showing the ellipsis >> while the user is actively typing in the focused control seems like fine >> behavior even for text-overflow. >> >> dave >> (hy...@apple.com) >> >> On Jan 13, 2012, at 2:45 PM, Ojan Vafai wrote: >> >>> Is this specced anywhere? Do we need a new CSS property? Could we just make >>> text-overflow work on text inputs? >>> >>> On Wed, Jan 11, 2012 at 11:30 PM, Jon Lee wrote: >>> Hi WebKit! >>> >>> I wanted to let you know that we would like to add a new CSS property >>> -webkit-control-text-overflow. It is a non-inheritable property that can >>> only be applied to single-line text inputs. Acceptable values are the same >>> as text-overflow, i.e. "clip" and "ellipsis". >>> >>> When the input is set with the "ellipsis" value, both the placeholder and >>> inner text value of the input render with an ellipsis if the text overflows >>> and the input is not focused. When the input becomes focused, the >>> placeholder or text value renders clipped, as before. >>> >>> Although this is a small enhancement to text controls, we think this is >>> especially useful for authors developing on the mac platform, since the >>> analog native widgets behave similarly. >>> >>> The bug that tracks this is: https://bugs.webkit.org/show_bug.cgi?id=76118 >>> >>> Jon >>> ___ >>> 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] New CSS property -webkit-control-text-overflow
I have the same question. Can you explain why text-overflow is insufficient? I think in this case it would be acceptable behavior to just make text-overflow behave the way you want, i.e., no longer showing the ellipsis while the user is actively typing in the focused control seems like fine behavior even for text-overflow. dave (hy...@apple.com) On Jan 13, 2012, at 2:45 PM, Ojan Vafai wrote: > Is this specced anywhere? Do we need a new CSS property? Could we just make > text-overflow work on text inputs? > > On Wed, Jan 11, 2012 at 11:30 PM, Jon Lee wrote: > Hi WebKit! > > I wanted to let you know that we would like to add a new CSS property > -webkit-control-text-overflow. It is a non-inheritable property that can only > be applied to single-line text inputs. Acceptable values are the same as > text-overflow, i.e. "clip" and "ellipsis". > > When the input is set with the "ellipsis" value, both the placeholder and > inner text value of the input render with an ellipsis if the text overflows > and the input is not focused. When the input becomes focused, the placeholder > or text value renders clipped, as before. > > Although this is a small enhancement to text controls, we think this is > especially useful for authors developing on the mac platform, since the > analog native widgets behave similarly. > > The bug that tracks this is: https://bugs.webkit.org/show_bug.cgi?id=76118 > > Jon > ___ > 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] Making overflow clipping cheaper
On Jan 4, 2012, at 2:36 PM, Julien Chaffraix wrote: >> namely RenderLayer is too generic for most cases and ends > up hurting performance. In what way? Overflow clips create layers, but they do not paint or hit test at the layer level unless they are self-painting layers. They only become self-painting layers if some other property is present that causes this to happen, e.g., absolute positioning. Perhaps you could point me to the specific performance problems that you're seeing that are caused by overflow and layers, since we already should be avoiding the self-painting layer code paths for overflow that doesn't need a layer for some other reason. Note I have no real objection RenderLayers using mix-ins or composition to bring in scrolling functionality. That seems sensible if that's all you're planning. I'd just like to understand the performance concerns more, since it's not clear to me what your specific performance issues are. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
I'd be careful in how I approach this. Some platforms are going to want compositing of overflow sections eventually for fast scrolling of those sections. RenderLayer has become the natural tie-in point for GraphicsLayer connections. In the future I envision overflow sections being more justified in having layers by virtue of the fact that they would always be composited. In a non-composited world, I can see why you might be tempted to yank overflow functionality out of RenderLayer, but in a composited world, having RenderLayers created for these objects makes more sense. dave (hy...@apple.com) On Dec 29, 2011, at 5:49 PM, Julien Chaffraix wrote: >> Wouldn't it be better to implement better searching and paint-segmentation in >> RenderLayers then? It could also provide the same speed up for many other big >> cases. > > That would be worth investigating more for sure (do you mind filing a > bug about it?). The paint search and segmentation algorithm is very > close between RenderLayer and most RenderObjects - tables being an > exception here as their structure enables better searching algorithms > - which means that it would benefit everyone. I haven't spend enough > time looking at generic scalability issues to say if there won't be > others more important bottlenecks. > > I still see some upsides in attacking the reduced use case of overflow > clips independently of what you are proposing: > * RenderLayer has become a class handling far too many tasks so moving > some functionality out of it is good by itself. > * RenderObject has a better knowledge of its own structure, something > as generic as RenderLayer would not need to be aware of. > > Thanks, > Julien > ___ > 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] vertical text
On Nov 11, 2011, at 7:59 AM, Cary Clark wrote: > Thanks for the answer, Dave. That makes perfect sense. > > Why is it that the graphics context is rotated but the advances supplied to > Font::DrawGlyphs in the GlyphBuffer aren't? > Right now fonts are broken up into two categories: ones that are considered "vertical" and ones that are considered "horizontal", but a "vertical" font uses a text-orientation-specific fallback when the glyphs are known to have flexible orientation, e.g., they could render upright or sideways depending on the value of the text-orientation property. The default value of text-orientation is vertical-right, meaning that these flexibly oriented glyphs should render rotated in a vertical text environment. However, because we rotated the graphics context, we are able to simply use the horizontal version of the font data in this case, and this allows us to reduce memory usage and re-use all the cached horizontal font information. Therefore the flexible glyph advances are unrotated and are just the horizontal font data information. Instead we rotate the glyphs that are always locked to an upright orientation in a vertical text environment. Those advances are the ones that are rotated. In effect you have a double rotation (the graphics context rotates, and then the inflexible glyphs get rotated again when drawing). This may seem backwards and somewhat confusing, but I can assure you we'd have to write way more code if we flipped things around (and we'd consume 2x the memory for glyph width storage for English letters). dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] vertical text
On Nov 10, 2011, at 4:07 PM, Cary Clark wrote: > TL;DR: Why is the graphics context rotated when drawing vertical text? I assume you're referring to the rotation done by InlineTextBox. The basic reason for the rotation was that it was a minimal change to the code and allowed a bunch of other drawing functions to remain unchanged. You could certainly eliminate the rotation, but you'd then have to patch all of the InlineTextBox drawing functions (underlines, selection, spell check markers, etc.) to be able to operate horizontally or vertically. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] old-run-webkit-tests is officially deprecated.
Has the issue with run-webkit-tests putting pixel tests in cross-platform directories instead of platform-specific directories been fixed? That was the showstopper for me. dave (hy...@apple.com) On Oct 27, 2011, at 5:00 PM, Eric Seidel wrote: > As of this afternoon, the Apple-Win bot is the only remaining buildbot > (to my knowledge) using old-run-webkit-tests > (https://bugs.webkit.org/show_bug.cgi?id=38756). > > Unfortunately, that's not likely to change soon. But all other > platforms (and all other developers) besides Apple-Win should be using > new-run-webkit-tests (it's automatically called for you when you run > run-webkit-tests). > > If you're still using old-run-webkit-tests for your work, I would > *love* to know and fix any issues you may have with NRWT. > > > In the next week I'll be moving run-webkit-tests from using a > white-list of NRWT-supported ports, to a black-list. Meaning any > private (or future) ports which may not be using NRWT yet will need to > switch, or we'll need to add a special exception in run-webkit-tests > for that port. > > Thank you for your patience in this process. I've started to burn > down the list of polish bugs > (https://bugs.webkit.org/show_bug.cgi?id=64491) and plan to close the > "switch all bots" bug (https://bugs.webkit.org/show_bug.cgi?id=34984) > once we move run-webkit-tests from whitelisting NRWT supported ports > to blacklisting ports which still require ORWT. > > -eric > ___ > 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] CSS Aspect Ratio Parsing Stage Up For Review
I'll take a look. I really like the proposal and the property definition. dave (hy...@apple.com) On Oct 24, 2011, at 12:01 AM, Fady Samuel wrote: > Hi all, > > I've uploaded the parsing stage for the -webkit-aspect-ratio property that > was proposed here: > > http://www.xanthir.com/blog/b4810 > > The parsing implementation can be found here: > > https://bugs.webkit.org/show_bug.cgi?id=70707 > > An old, experimental implementation of the entire feature was uploaded last > year: > > https://bugs.webkit.org/show_bug.cgi?id=47738 > > and discussed here: > > http://lists.w3.org/Archives/Public/www-style/2010Oct/0046.html > > http://lists.w3.org/Archives/Public/www-style/2011Oct/0550.html > > I was wondering if anyone would be interested in reviewing this and getting > this incorporated into WebKit? > > Thanks, > > Fady > ___ > 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] RefPtr/PassRefPtr Question
I am getting complaints from check-webkit-style in a bug regarding PassRefPtr/RefPtr usage, and I can't figure out what I should be doing. It yells at me no matter what I try. The scenario I have is that a function is wanting to transfer ownership but it's not doing it via a return value. Instead it is filling in a reference parameter. The current code looks like this: Caller: RefPtr myLocal; bool success = myFunc(myLocal); With the function being: bool myFunc(RefPtr& result); With this setup though, I get yelled at by the style checker and it tells me that the parameter should be a PassRefPtr. However I don't get how I can do that, since then I have: PassRefPtr myLocal; and I get yelled at for making a PassRefPtr local variable. What's the right way to write this code such that it will pass? Is this just a flaw in the style checker? It sure seems like a RefPtr reference parameter should be allowed... dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
Writing a new XML parser is a complete waste of time. If libxml has problems, fix them. If you throw out libxml, you'd have to throw out libxslt as well. The end result is not worth the engineering effort it would take to build it and make it work better than libxml/libxslt. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave > On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: > >> Hi webkit-dev, >> >> I wanted to let you know that Ojan and I plan to add flexbox layout support >> to WebCore. WebCore already supports an older flexbox implementation >> (display: box), but the new spec is designed to be easier for developers to >> understand and more powerful. The old flexbox will still remain in WebCore >> since none of the CSS properties overlap with the new flexbox spec. The >> spec can be found at: http://www.w3.org/TR/css3-flexbox/ >> (http://dev.w3.org/csswg/css3-flexbox/) >> >> This support will be behind the ENABLE_FLEXBOX feature define >> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug >> tracking the feature's development >> (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to >> eventually be enabled by all ports. >> >> I am ready to setup a buildbot for tracking the compile and flexbox related >> layout tests. Should I go ahead and get this added to build.webkit.org's >> waterfall? >> >> Thanks, >> Tony >> >> ___ >> 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] Parallel CSS styling
I'll just re-iterate what Simon was saying. We're very interested in improving CSS performance where it's needed, but I would definitely make sure non-parallel optimization options have been exhausted first. I think there are still some very big gains to be made selector matching even before trying to parallelize it. I'm not necessarily opposed to parallelization, but I believe it's pretty difficult to implement correctly. It's pretty easy to produce a naive parallelization that will look like it works but have correctness and stability bugs. I'm not saying that's what you did, but there are some real subtleties with parallelization that you might not be taking into account. dave (hy...@apple.com) On Jun 7, 2011, at 1:54 PM, Eric Seidel wrote: > You noted it spends 66% of its "CSS time" in StyleForElement. What > about total page load time? > > Then again 6450ms spent in CSS sounds like a lot of time regardless. > Answering what % of total page load time we're spending in CSS (or > StyleForElement) is important. > > Loading www.flickr.com/photos/tags/sanfrancisco on my 4-core 2.66ghz > Mac Pro doesn't take anywhere near 6 (or for that mater 9!) seconds, > so I'm confused how you got 9s in CSS code on a (supposedly faster) > machine loading that flickr page. > > I'm building WebCore so I can shark the page now. > > Thanks again for your investigation efforts. > > -eric > > On Tue, Jun 7, 2011 at 11:22 AM, Kulanthaivel Palanichamy > wrote: >> Eric, >> >> You're right that in flickr.com main page, Webkit spends very little time >> in StyleForElement. However, if you visit >> http://www.flickr.com/photos/tags/sanfrancisco/ , WebKit spends most of >> its CSS time in StyleForElement. For example, in our test machine (an >> 8-core Intel Xeon, 2.8GHz) StyleForElement takes 6450ms out of 9748 ms >> spent on CSS (66%). Our algorithm focuses on that 66%, and makes it scale >> linearly. The version of Webkit that we tested includes this patch: Bug >> 49876 - Optimize matching of descendant selectors >> >> Other websites that would benefit: >> • amazon (68% in SFE) >> • Google search (57%) >> • Yahoo sports (56%) >> • Apple (58%) >> • Wikipedia article (65%) >> >> -Kulanthaivel >> >>> Do you have statistics on how much total time rendering flickr.com is >>> in CSS/Style code at all? I believe it to be very low. >>> >>> -eric >>> >>> On Mon, Jun 6, 2011 at 1:16 PM, Kulanthaivel Palanichamy >>> wrote: Hi All, At Qualcomm Innovation Center we have been working on a parallel algorithm for CSS styling and wanted to see if there is any interest in the community to see it implemented in WebKit. The overall idea is that we replace CSS matching and styling with a parallel implementation assuming there is a barrier before and after the computation. CSS style application will be performed by the main thread, such that we avoid the need to make thread safe data structures accessed in other passes. The algorithm is task-based, so we would need to implement a thread pool and a simple task scheduler (or maybe use an existing one). In particular, our algorithm requires modifying Element::recalcStyle() and some of the methods it invokes. Code that calls Element::recalcStyle() will not have to be changed. By the time Element::recalStyle() returns, all threads involved on the parallel CSS styling have completed their execution. Effectively, there is a barrier when Element::recalcStyle() begins and another before it returns. Our experiments show that our CSS computation for complex websites scales rather well. For example, we observed that, for flickr.com, Webkit spends 75% of its time in CSS doing CSS matching. Thus, our algorithm would give a maximum speedup of 1.6X on 2 cores and 2.3X on 4 cores. Please let us know whether this would be of interest to the community. -Kulanthaivel ___ 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] Adding CSS Regions and Exclusions to WebKit
On May 26, 2011, at 4:31 PM, Eric Seidel wrote: > I appreciate that you've followed the master-bug idiom which is so common in > bugs.webkit.org these days! > > I also would *strongly* encourage you to post your changes in as small of > patches as possible. Integrating features which have been developed outside > webkit.org is always difficult, but doing things in small (or even tiny!) > patches will make your life easiest in the long run. > > I'm happy to help review your (small!) changes if CC'd. I've encouraged them to begin with the CSS property back end, i.e., getting the new properties and values in and parsed. I think it will be a good introduction to our process to start there, and it will also let them get familiar with writing regression tests. I think those patches are more easily reviewed by many people as well, unlike the layout and rendering changes, which are quite advanced. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
On Apr 6, 2011, at 3:01 PM, Charles Pritchard wrote: > On 4/6/2011 12:32 PM, David Hyatt wrote: >> He wants a way to detect Desktop zoom (which is done two different ways in >> WebKit). It's difficult to figure out how to expose these, since Desktop >> zoom is ultimately just the CSS zoom property, which can be applied to any >> element (so folding it into a global makes little sense). The other kind of >> Desktop zoom that involves a fixed scale factor applies a transform. Again, >> transforms can be applied to descendant elements as well, so relying solely >> on what happened to be specified at the document level makes little sense. > The descendant elements are under the control of the author. > > That is, if I decide to use body.style.webkitTransform, in my scripting > environment, I'm going to know that, > because I initiated the request, and I'll add that to my calculations. > Yeah, that's a good point. > I see adding a pixel ratio property to window.screen as the cleanest solution. This seems like a decent solution to me. Probably simplest to just match what WinIE did for compatibility (even though it's two properties). dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
He wants a way to detect Desktop zoom (which is done two different ways in WebKit). It's difficult to figure out how to expose these, since Desktop zoom is ultimately just the CSS zoom property, which can be applied to any element (so folding it into a global makes little sense). The other kind of Desktop zoom that involves a fixed scale factor applies a transform. Again, transforms can be applied to descendant elements as well, so relying solely on what happened to be specified at the document level makes little sense. I'm not really sure how to easily solve this problem. I suppose we could just mix in document-level zoom and transform state into devicePixelRatio, but that feels inelegant to me given that individual child elements can change the zoom and transform. It wouldn't necessarily be accurate. I also don't like the idea of having to re-resolve style just because the zoom level changed. That would just slow things down. dave (hy...@apple.com) On Apr 6, 2011, at 9:17 AM, Darin Adler wrote: > On Apr 5, 2011, at 9:52 PM, Charles Pritchard wrote: > >> Long-story-short, can we please expose some of the CSS pixel scaling, either >> through window.devicePixelRatio > > I typed javascript:alert(devicePixelRatio) in Safari on my iPhone 4, and got > the value 2. > > Isn’t this what you are asking for? > >-- Darin > > ___ > 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] Use of -webkit- prefix on CSS Values and Properties
Yeah, I'd prefer not to prefix :not. (Haha.) In fact :not used to actually support more complex selectors, and I had to dumb it down to pass stupid CSS 2.1 tests that deliberately checked for the lack of complexity... so all we'd be doing is going back to our old behavior. We should probably make sure those tests are not in the current version of the suite though. dave (hy...@apple.com) On Mar 30, 2011, at 10:50 AM, Simon Fraser wrote: > If the change is backwards compatible (i.e. if you don't break the behavior > described in Selectors 3), then I don't think it needs to be prefixed. > > What have other vendors done? > > Simon > > On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote: > >> What's the right thing to do for something that is in a CR spec, but the >> draft spec for the next version has it behave differently? Specifically, in >> Selectors 3, :not only accepts a single simple selector. In Selectors 4, it >> accepts a comma separated list of compound selectors (a superset of the >> Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994. >> >> I see three options: >> 1. Wait until Selectors 4 hits CR before changing :not. >> 2. Implement :-webkit-not to match Selectors 4 and leave :not matching >> Selectors 3. >> 3. Make :not match Selectors 4. >> >> My preference in this instance is option 3. >> >> Ojan >> >> On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt wrote: >> As was mentioned already, we've been trying to follow the general guideline >> of dropping the prefix when a draft hits CR and keeping it otherwise. An >> exception to this rule is if our syntax has not yet been updated to match >> the CR syntax, in which case we keep the prefix. >> >> dave >> >> ___ >> 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] Use of -webkit- prefix on CSS Values and Properties
As was mentioned already, we've been trying to follow the general guideline of dropping the prefix when a draft hits CR and keeping it otherwise. An exception to this rule is if our syntax has not yet been updated to match the CR syntax, in which case we keep the prefix. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?
-webkit-tap-highlight-color: transparent is what you need I suspect (at least for iOS). dave (hy...@apple.com) On Mar 11, 2011, at 10:33 AM, Alex Milowski wrote: > I'm not sure this is exactly the right place to start, but I'll start > here since the intersection of Andriod, iOS, and other developers are > here. > > I've been testing some ideas for using the HTML5 canvas on mobile > platforms versus desktop and I've notice an annoying "feature" on the > mobile platforms. It is most noticeable on Android but also shows up > on iOS on the iPad or iPod touch devices. > > The application involves the use of a HTML5 canvas that intercepts > touch events on the canvas. Areas of a geometric image changes > shading when touched to represent fractions of the object. On both > platforms, there seems to be something about focus from the touch even > that causes a highlight for the whole box containing the canvas > element. > > On iOS, a gray shaded version of the canvas shows up for a very, very > short period of time. It is inconsistent and depends how long the > touch gesture is on the canvas. Some very short touch gestures do now > cause the highlight of the canvas. That may be because it is just too > short of a period of time to draw the highlight. > > On Andriod, any touch gesture cases a border and highlight around the canvas. > > Both are undesired effects. > > I'm trying to understand why the canvas has special highlight features > for touch gestures over any other rendering object. Looking at the > code, the highlight seems to be from the fact that RenderHTMLCanvas > inherits from RenderReplaced just like RenderImage does. It all seems > to key off of whether the canvas is selected. But the highlight isn't > there for mouse clicks on desktop platforms. > > None of the CSS tricks (e.g. -webkit-user-select: none) seem to help > on mobile platforms. > > It seems to me that on touch-enabled platforms (e.g. mobile) you > should be able to disable this selection highlight behavior for canvas > somehow. > > -- > --Alex Milowski > "The excellence of grammar as a guide is proportional to the paucity of the > inflexions, i.e. to the degree of analysis effected by the language > considered." > > Bertrand Russell in a footnote of Principles of Mathematics > ___ > 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] Line box tree converting from int -> float
https://bugs.webkit.org/show_bug.cgi?id=54244 A patch is on its way that is going to be converting the line box tree from being int-based to being float-based. All of the rounding hacks for word rounding and run rounding when measuring and drawing text will be eliminated. The unfortunate side effect of such a patch, however, is that many many layout test results are changing on Mac (and I will be updating those test results). The effects on ports that use integer advances for glyphs should be minimal. If your platform has been returning non-integral values for advances, however, then expect many test results on your platform to change because of the improved precision. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rebaselining render tree dumps
On Dec 6, 2010, at 4:12 PM, Dan Bernstein wrote: > > (6) There’s something called RenderBody ;-) LOL yeah. I forgot about that one. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rebaselining render tree dumps
On Dec 6, 2010, at 3:20 PM, Dirk Pranke wrote: > I think this is a great idea. I have one suggestion and one > potentially large, derailing comment :) > > Suggestion: in theory, fixing the render tree output shouldn't change > the pixel output. So, I would suggest that as many ports as possible > should be running (up-to-date) pixel tests when do have this flag day. > Yeah, that's a really good observation. The pixel tests will help us know that the changes to the dump didn't regress anything. > Large, potentially derailing comment -- would this be an opportune > time to try and codify the intent of the rendertree output at all? We > are geting close to having support for reftests (finally!), and we > have dumpAsMarkup() now as well. It seems to me that a lot of the > original intent for render tree output may have been replaced by > better alternatives now (not that I'm suggesting we rewrite all of the > tests prior to this flag day). > We definitely should be reducing the use of the render tree dump. There are a number of areas where reftests are extremely difficult though. Vertical text and multi-column layout are both examples where reftests are virtually impossible. I think reftests for certain kinds of transforms and compositing could be difficult as well. The biggest benefit of render tree dumps is that they tell you about the geometry and style of scrolled or clipped content. Therefore they catch bugs that pixel tests don't see (and if reftests compare based off visible pixels then they would not see the error either). This is the case with any tests that have scrolled or clipped content. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Rebaselining render tree dumps
RenderTreeAsTetxt has a large number of hacks in it that have been put in over time to keep the dumps from changing too dramatically. Some of these include: (1) Table cells dump incorrect dimensions and positions. (2) Text nodes dump an incorrect bounding box position. (3) RenderInlines don't dump their position at all. (4) The root layer incorporates overflow when it shouldn't. (5) The root element has a RenderLayer when there has been no need for it to have a RenderLayer for years. It only has one in order to not change all the layout tests. In addition there is information not being captured that would be useful to include in the dump. Examples of this include: (1) Layout and visual overflow for elements. Right now we're completely dependent on repaint tests to catch changes in visual overflow. (2) scrollOrigin for the ScrollView and for overflow sections. (3) intrinsic padding of table cells. (4) Transforms and relative positioning offsets I'm sure people may have other ideas about things to include in the geometry dumps that aren't there right now, so send me your suggestions. What I'd like to do is have a rebaselining day (probably after the holidays in January) where we just shut the tree down and all the ports rebaseline to the new format (with the hacks removed and any changes we want to make added). What do people think of this idea? How can we make sure that a rebaselining like this goes smoothly? dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
An example of nice boolean usage is: paintTextWithShadows(context, font, textRun, 0, length, length, textOrigin, boxRect, textShadow, textStrokeWidth > 0, isHorizontal()); GOOD! The last parameter is a boolean indicating whether or not the text run is vertical text or horizontal text. It would be unreadable if you passed raw true or raw false to the function, but all the call sites pass isHorizontal(), so it's perfectly fine. paintTextWithShadows(context, font, textRun, 0, length, length, textOrigin, boxRect, textShadow, textStrokeWidth > 0, true); BAD! dave (hy...@apple.com) On Dec 3, 2010, at 4:30 PM, Darin Adler wrote: > On Dec 3, 2010, at 1:37 PM, David Hyatt wrote: > >> The only exception I would make to this rule is if all the call sites use >> variables and never pass in raw true or false. In that case there's no loss >> of readability, and whether you use an enum vs. a bool is irrelevant. > > That’s right. There are cases where the boolean value passed in for a > particular argument is typically the result of a boolean expression or > boolean-returning function. We have definitely seen these in patch review. > >> I think in general the rule should be "Keep your call sites readable, and >> convert to enums if you find that the call sites are becoming inscrutable." > > Beyond the enum guidelines, it’s also true that functions with these > boolean/enum arguments often indicate minor design mistakes. Many times we > would be better off with multiple functions rather than a single function > with an enum argument. > >-- Darin > > ___ > 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] Bools are strictly worse than enums
On Dec 3, 2010, at 3:33 PM, Darin Fisher wrote: > On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote: > It seems to me, that using bool types for function arguments is strictly > worse than using an enum. An enum is always clearer and can be easily casted > to a bool if needed. > > doSomething(something, false); > > Is much less readable than: > > doSomething(something, AllowNetworkLoads); > > > Do any C++ gurus have further information to add here? Is my (simple) > analysis here incorrect? If not, seems we should forbid boolean values in > multi-argument methods/constructors in our style and add checks to > check-webkit-style to prevent further introduction of these confusing > callsites. > > -eric > > > I was under the impression that this was already an encouraged style in > WebKit code. At least, I really like that is makes call-sites more > self-documenting. The only exception I would make to this rule is if all the call sites use variables and never pass in raw true or false. In that case there's no loss of readability, and whether you use an enum vs. a bool is irrelevant. I think in general the rule should be "Keep your call sites readable, and convert to enums if you find that the call sites are becoming inscrutable." dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
Yeah, that demo makes me think maybe 9px is fine after all. :)
dave
On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote:
> I think 5px is way too small. Maybe 7 or 8 at least but even those are
> really hard to read in high-resolution displays. See demo.
>
> - Ryosuke
>
> On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt wrote:
> That document also states:
>
> "When the size of base characters is very small (for e.g. smaller than seven
> points), ruby which is half the size, will be even more small and illegible.
> In such cases where the size of base characters is very small, ruby is not a
> suitable method of annotation. In those cases, consider other annotation
> methods such as adding the reading in parenthesis immediately after the base
> character.
>
> It also sounds like we need to special case Ruby elements and allow their
> font sizes to go down to about 5px instead of 9px. Anything lower, and
> you're getting to the point where ruby was unsuitable (according to the text
> above) anyway, since the base text was so small.
>
> I filed:
>
> https://bugs.webkit.org/show_bug.cgi?id=48942
>
> dave
> (hy...@apple.com)
>
> On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:
>
>> In printing the standard is 50% of the base text. For larger point sizes
>> like headings, the size of ruby is often smaller than 50%.
>>
>> http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
>>
>> So, how about we default to 50% and see how they come out. Glyphs designed
>> for ruby are optimized for those small point sizes. It is possible on some
>> screen resolutions we might want to make it a bit bigger but as screen
>> resolution gets higher I think it makes more sense to stick to 50% following
>> the standard in printing.
>>
>> - kida
>>
>> On 2010/11/03, at 12:05, Eric Mader wrote:
>>
>>>
>>> On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
>>>
>>>> WebKit enforces a minimum font size of 9px when no explicit font size is
>>>> specified. This means that the font for cannot fall below 9px if it
>>>> is relative to the user agent default. It may be that we want to consider
>>>> modifying this minimum for ruby text and allow it to go below 9px though.
>>>> I'm not sure.
>>>
>>> Yes, that's probably what I'm seeing. I'm using default font size, which is
>>> probably 12pt.
>>>
>>>> If you make a really big Ruby (e.g., and
>>>> then modify the font-size percentage on the , you should be able to
>>>> see it take effect.
>>>>
>>>> We should probably just study real-world Japanese examples to see how
>>>> small Ruby typically is allowed to get. If it can go below 9px and still
>>>> be readable, we should perhaps consider allowing that.
>>>
>>> I'm sure the detailed spec. addresses this issue. I'll review it.
>>>
>>>> In terms of excluding Ruby text from the overall line height, I don't
>>>> think the font-size of the is particularly relevant. You just want
>>>> to hack the Ruby to turn the ruby text into overflow rather than having it
>>>> be part of the overall height of the inline-block.
>>>
>>> Of course. The website I was using has the line height set too tight for
>>> correct display this way, and I just wanted to try a smaller size to see if
>>> it looked better. OTOH, that site loads a style sheet that overrides the
>>> ruby text font-size to 6pt, so I can't easily override it, and its'
>>> probably displaying as 9pt anyhow.
>>>
>>>> dave
>>>> (hy...@apple.com)
>>>
>>> Regards,
>>> Eric
>>>
>>>> On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As part of my work on ruby text enhancements, I'm implementing the option
>>>>> of not counting the height of the ruby text in the overall line height.
>>>>> As part of this, I wanted to play with changing the size of the ruby
>>>>> text. I'm trying to do this by changing the following lines in
>>>>> /WebCore/css/html.css:
>>>>>
>>>>> ruby > rt {
>>>>> display: block;
>>>>> font-size: 60%; /* make slightly larger than 50% for better
>>>>> readability */
>>>>> text-align: center;
>>>>> text-decoration: n
Re: [webkit-dev] Size Of Ruby Text?
That document also states:
"When the size of base characters is very small (for e.g. smaller than seven
points), ruby which is half the size, will be even more small and illegible. In
such cases where the size of base characters is very small, ruby is not a
suitable method of annotation. In those cases, consider other annotation
methods such as adding the reading in parenthesis immediately after the base
character.
It also sounds like we need to special case Ruby elements and allow their font
sizes to go down to about 5px instead of 9px. Anything lower, and you're
getting to the point where ruby was unsuitable (according to the text above)
anyway, since the base text was so small.
I filed:
https://bugs.webkit.org/show_bug.cgi?id=48942
dave
(hy...@apple.com)
On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:
> In printing the standard is 50% of the base text. For larger point sizes like
> headings, the size of ruby is often smaller than 50%.
>
> http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
>
> So, how about we default to 50% and see how they come out. Glyphs designed
> for ruby are optimized for those small point sizes. It is possible on some
> screen resolutions we might want to make it a bit bigger but as screen
> resolution gets higher I think it makes more sense to stick to 50% following
> the standard in printing.
>
> - kida
>
> On 2010/11/03, at 12:05, Eric Mader wrote:
>
>>
>> On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
>>
>>> WebKit enforces a minimum font size of 9px when no explicit font size is
>>> specified. This means that the font for cannot fall below 9px if it
>>> is relative to the user agent default. It may be that we want to consider
>>> modifying this minimum for ruby text and allow it to go below 9px though.
>>> I'm not sure.
>>
>> Yes, that's probably what I'm seeing. I'm using default font size, which is
>> probably 12pt.
>>
>>> If you make a really big Ruby (e.g., and then
>>> modify the font-size percentage on the , you should be able to see it
>>> take effect.
>>>
>>> We should probably just study real-world Japanese examples to see how small
>>> Ruby typically is allowed to get. If it can go below 9px and still be
>>> readable, we should perhaps consider allowing that.
>>
>> I'm sure the detailed spec. addresses this issue. I'll review it.
>>
>>> In terms of excluding Ruby text from the overall line height, I don't think
>>> the font-size of the is particularly relevant. You just want to hack
>>> the Ruby to turn the ruby text into overflow rather than having it be part
>>> of the overall height of the inline-block.
>>
>> Of course. The website I was using has the line height set too tight for
>> correct display this way, and I just wanted to try a smaller size to see if
>> it looked better. OTOH, that site loads a style sheet that overrides the
>> ruby text font-size to 6pt, so I can't easily override it, and its' probably
>> displaying as 9pt anyhow.
>>
>>> dave
>>> (hy...@apple.com)
>>
>> Regards,
>> Eric
>>
>>> On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
>>>
>>>> Hi,
>>>>
>>>> As part of my work on ruby text enhancements, I'm implementing the option
>>>> of not counting the height of the ruby text in the overall line height. As
>>>> part of this, I wanted to play with changing the size of the ruby text.
>>>> I'm trying to do this by changing the following lines in
>>>> /WebCore/css/html.css:
>>>>
>>>> ruby > rt {
>>>> display: block;
>>>> font-size: 60%; /* make slightly larger than 50% for better
>>>> readability */
>>>> text-align: center;
>>>> text-decoration: none;
>>>> }
>>>>
>>>> However, when I change the font-size: attribute to, say, 50%, I don't see
>>>> any difference in the size of the ruby text. (I even tried 25% just to be
>>>> sure). Is this value being set somewhere else?
>>>>
>>>> Regards,
>>>> Eric Mader
>>>>
>>>> ___
>>>> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
On Nov 3, 2010, at 2:05 PM, Eric Mader wrote: > > Of course. The website I was using has the line height set too tight for > correct display this way, and I just wanted to try a smaller size to see if > it looked better. OTOH, that site loads a style sheet that overrides the ruby > text font-size to 6pt, so I can't easily override it, and its' probably > displaying as 9pt anyhow. We honor small explicitly set font sizes. The 9px minimum is only enforced when it's impossible for the site to know what the real font size would have been, i.e., if you are relative to the user agent default. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Size Of Ruby Text?
WebKit enforces a minimum font size of 9px when no explicit font size is
specified. This means that the font for cannot fall below 9px if it is
relative to the user agent default. It may be that we want to consider
modifying this minimum for ruby text and allow it to go below 9px though. I'm
not sure.
If you make a really big Ruby (e.g., and then
modify the font-size percentage on the , you should be able to see it take
effect.
We should probably just study real-world Japanese examples to see how small
Ruby typically is allowed to get. If it can go below 9px and still be
readable, we should perhaps consider allowing that.
In terms of excluding Ruby text from the overall line height, I don't think the
font-size of the is particularly relevant. You just want to hack the Ruby
to turn the ruby text into overflow rather than having it be part of the
overall height of the inline-block.
dave
(hy...@apple.com)
On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
> Hi,
>
> As part of my work on ruby text enhancements, I'm implementing the option of
> not counting the height of the ruby text in the overall line height. As part
> of this, I wanted to play with changing the size of the ruby text. I'm trying
> to do this by changing the following lines in /WebCore/css/html.css:
>
> ruby > rt {
> display: block;
> font-size: 60%; /* make slightly larger than 50% for better readability */
> text-align: center;
> text-decoration: none;
> }
>
> However, when I change the font-size: attribute to, say, 50%, I don't see any
> difference in the size of the ruby text. (I even tried 25% just to be sure).
> Is this value being set somewhere else?
>
> Regards,
> Eric Mader
>
> ___
> 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] Coding style change - Indentation of forward declarations in headers
Yeah I agree with Peter. I think blank lines after { and before } would
improve the readability of the 2nd example even without indentation.
namespace WebCore {
class AuthenticationChallenge;
class CachedFrame;
class HistoryItem;
class ProtectionSpace;
class ResourceLoader;
class ResourceRequest;
}
This doesn't seem worth making a special case for to me.
dave
(hy...@apple.com)
On Nov 1, 2010, at 11:49 AM, Peter Kasting wrote:
> On Mon, Nov 1, 2010 at 9:40 AM, Brady Eidson wrote:
> I think this pattern increases readability of forward declarations in headers
> and we should change the style guidelines to specify its continued use.
>
> Thoughts?
>
> I don't find either one significantly better than the other, personally.
>
> PK
> ___
> 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] Line breaking
Pick me! Pick me! On Oct 29, 2010, at 1:54 AM, Adam Barth wrote: > In looking at a bunch of web compat bugs filed in the Chromium bug > tracker, it seems like WebKit's line breaking behavior is a major > source of compatibility problems. I'm currently writing a test suite > to reverse engineer the line breaking behavior of other browsers. I'm > not familiar with the history of WebKit's line breaking behavior. Who > would be a good person to talk with about these issues? > > Thanks, > Adam > ___ > 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] Focus Crash Relating to MathML
Also, if your pattern of code in a layout method is (1) Call base class RenderBlock::layout (2) Do other stuff that might cause dirtying Then you should really bulletproof that code by adding (1) Call base class RenderBlock::layout (2) Do a setChildNeedsLayout(true, false) on yourself just to make yourself already dirty. (3) Do other stuff that might cause dirtying (4) Do a setNeedsLayout(false) We don't really have a good setup for calling base class layout methods... technically you should stay dirty throughout the lifetime of your own layout method, but the base class method will mark you as "clean." We should come up with something better at some point, but for now I think if you just dirty for the rest of the code you want to run and then mark yourself clean at the end, you'd stop the problem as well. dave On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote: > On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt wrote: >> (1) Make sure any layout methods you call do setNeedsLayout(false) at the >> end of them. >> (2) Look for any early returns in any of your layout methods, since maybe >> you did an early return causing the setNeedsLayout(false) to be missed. >> (3) Make sure you aren't dirtying a child for a re-layout without >> immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, >> false) on some child and then bail without doing a layout. > > While this is helpful, the current code (in the patch) follows these > principles (except when RenderBlock::layout() is called last and so > setNeedsLayout(false) is already done). The problem I have is an > *ancestor* is marked as having a child needing layout during the > layout process. When then MathML layout finishes, the MathML > rendering objects do not need layout but the parent is marked with > m_normalChildNeedsLayout set to true. > > This only becomes a problem when the parent of the RenderMathMLMath > rendering object is a RenderInline instance as the a RenderBlock will > call setNeedsLayout(false) on itself at the very end of layout. To > me, although I have yet to confirm this, it seems like > setNeedsLayout(false) is called during the layout of the inline flow > from RenderBlock::layoutInlineChildren() on the RenderInline instance > and then the RenderInline is marked with a child needing layout. > Unfortunately, none of the above suggestions are going to fix that. > > I think the call to destroyLeftoverChildren() is also something we > should reconsider. In my very simple example, this is what is causing > the RenderInline instance to be marked with a child needing layout as > it causes a traversal through the ancestors. I know why it is there > but it doesn't necessarily seem like the right way (or place) to > reorganize the operator stacking. > > -- > --Alex Milowski > "The excellence of grammar as a guide is proportional to the paucity of the > inflexions, i.e. to the degree of analysis effected by the language > considered." > > Bertrand Russell in a footnote of Principles of Mathematics > ___ > 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] Focus Crash Relating to MathML
On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:
> On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt wrote:
>> (1) Make sure any layout methods you call do setNeedsLayout(false) at the
>> end of them.
>> (2) Look for any early returns in any of your layout methods, since maybe
>> you did an early return causing the setNeedsLayout(false) to be missed.
>> (3) Make sure you aren't dirtying a child for a re-layout without
>> immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true,
>> false) on some child and then bail without doing a layout.
>
> While this is helpful, the current code (in the patch) follows these
> principles (except when RenderBlock::layout() is called last and so
> setNeedsLayout(false) is already done). The problem I have is an
> *ancestor* is marked as having a child needing layout during the
> layout process. When then MathML layout finishes, the MathML
> rendering objects do not need layout but the parent is marked with
> m_normalChildNeedsLayout set to true.
>
Ok, just speculating from eyeballing the code I think layoutInlineChildren
should do setNeedsLayout(false) on inlines when the end of the inline is
encountered rather than the start of it.
The iteration order is start of inline -> contents of inline -> end of inline,
and we do setNeedsLayout(false) at the start of the inline. If the contents of
the inline end up causing a dirtying up the chain, then this will not be caught
and cleared.
else if (o->isText() || (o->isRenderInline() && !endOfInline)) {
if (fullLayout || o->selfNeedsLayout())
dirtyLineBoxesForRenderer(o, fullLayout);
o->setNeedsLayout(false);
if (!o->isText())
toRenderInline(o)->invalidateVerticalPosition(); // FIXME:
Should do better here and not always invalidate everything.
}
In that code above I think !endOfInline should maybe just become endOfInline
instead.
dave
(hy...@apple.com)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
(1) Make sure any layout methods you call do setNeedsLayout(false) at the end of them. (2) Look for any early returns in any of your layout methods, since maybe you did an early return causing the setNeedsLayout(false) to be missed. (3) Make sure you aren't dirtying a child for a re-layout without immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, false) on some child and then bail without doing a layout. dave On Oct 18, 2010, at 10:22 PM, Alex Milowski wrote: > Most of the MathML rendering objects have a display style property value > of inline-block. Whenever these rendering objects are used, somehow the > parent "container" gets marked as having children in need of layout. The > MathML math rendering object completes its layout and marks itself as > not needing layout. In the end, the container (e.g. the anchor element) > render object has itself in a state where m_normalChildNeedsLayout is > true but no child is marked as needing layout. > > I've gone through the MathML rendering objects and remove all uses > of markContaingBlocksForLayout() and setNeedsLayoutPrefWidthsRecalc() > which generally cause the container to be marked with a child needing > layout. These calls were unnecessary and the resulting code should be > more efficient. > > In situations where the MathML does not contain a rendering object > that is an inline-block, everything works fine. For example: > > > x > > > Keep in mind, in the above, the 'mi' element just uses RenderInline as it > has no special semantics as of yet. > > In cases where specialized render objects (typically with display > inline-block) are used (e.g. an operator), the assert fires: > > > x > > > At this point, I don't think my code is directly causing the anchor to > get marked > with a child needing layout. I do rely on RenderBlock::layout() within most > of the rendering objects to handle the actual layout after adjustments. > > I've tried making sure that the parent or container schedule a re-layout but > that hasn't really helped. > > You can see all these adjustments and optimizations in the patch for: > > https://bugs.webkit.org/show_bug.cgi?id=43462 > > Any ideas of what to look at next would be appreciated. > > > -- > --Alex Milowski > "The excellence of grammar as a guide is proportional to the paucity of the > inflexions, i.e. to the degree of analysis effected by the language > considered." > > Bertrand Russell in a footnote of Principles of Mathematics > ___ > 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] Selection Highlight and MathML
Do the objects actually overlap each other? dave On Oct 14, 2010, at 8:58 PM, Alex Milowski wrote: > On Thu, Oct 14, 2010 at 5:19 PM, Darin Adler wrote: >> On Oct 14, 2010, at 2:12 PM, Alex Milowski wrote: >> >>> I'm curious as to why MathML seems to be treated differently for selection >>> highlights. >> >> Differently from what? I’m not sure what your question is. > > If you try out the attachment from the bug you'll see what I mean. > Essentially, MathML > seems to get several overlapping highlights that get darker and darker the > more > that they overlap via several layers. As such, the content eventually > gets washed > out by the highlight color. > > I do not see this behavior for non-MathML content and that leads me to > believe we need to something in the rendering objects for MathML. > > > -- > --Alex Milowski > "The excellence of grammar as a guide is proportional to the paucity of the > inflexions, i.e. to the degree of analysis effected by the language > considered." > > Bertrand Russell in a footnote of Principles of Mathematics > ___ > 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] Ruby Text Enhancements
On Oct 5, 2010, at 7:33 PM, Eric Mader wrote: > > On Sep 24, 2010, at 8:02 PM, David Hyatt wrote: > >> This is a tough problem. It seems like you have to get involved in the line >> layout code e.g., findNextLineBreak in order to really do the right thing. >> findNextLineBreak uses an iterator that walks the objects, so it's easier to >> tell what text came before you and what text comes after you. You can also >> tell whether or not that text will even fit on the line and possibly do the >> margin hacking there. > > I just did a prototype that checks for a RenderRubyRun in the isReplaced() > code inside findNextLineBreak and calls a method on the RenderRubyRun that > takes the last and the next object and sets negative margins by calling > setMarginLeft() and setMarginRight(). I stepped through this code and it > computes the correct margins, but the margins don't seem to take - the ruby > doesn't overlap the surrounding text. > > Guessing that some other code is resetting the margins, I modified the code > to cache the computed margins in the RenderRubyRun object and return the > cached values through subclassed marginLeft() and marginRight() methods. With > this change, the ruby displays as I would expect. It's probably RenderBlockLineLayout line 348 getting you in trouble (computeInlineDirectionPositionsForLine). computeLogicalWidth is called again, and that will recompute the left/right margins and blow away the changes you made to them. I have no idea why that call is there. It should not be necessary, but maybe there's something subtle I'm missing. You could try removing it, and see if that fixes the problem (it should). dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Oct 4, 2010, at 10:49 PM, Simon Fraser wrote: > On Oct 4, 2010, at 6:59 PM, Kenichi Ishibashi wrote: > >> I'd like to implement CSS ime-mode property, which >> activates/deactivates input methods, to WebKit. Here is the MDC's >> document about this property: >> >> https://developer.mozilla.org/en/CSS/ime-mode >> >> This property is not a part of any public standard, but both of IE and >> Firefox support this property. Like Safari and Chrome, they are widely >> used browsers so the ime-mode property is frequently used when one >> wants to control input methods. So, if WebKit supports this property, >> it would improve compatibility of web pages and make web developers >> easier to implement their pages and services. >> >> I recently posted a patch to support the ime-mode property for mac >> (See https://bugs.webkit.org/show_bug.cgi?id=21279), but alexey asked >> me to discuss at WHATWG mailing list whether we really should >> implement this property. Before going to WATWG, I'd like to ask >> opinions from webkit-dev mailing list. > > CSS properties should be discussed on www-style, not what-wg. If it helps with WinIE compatibility, I have no real objection to adding the property. I do find it unfortunate that Microsoft implemented this feature as a CSS property though. I think it should have been done as an extension to HTML instead. Turning off CSS shouldn't break the author's IME intent. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby Text Enhancements
On Sep 28, 2010, at 12:20 PM, Yasuo Kida wrote: > > On 2010/09/28, at 10:11, David Hyatt wrote: >> On Sep 27, 2010, at 3:40 PM, Eric Mader wrote: >>> Are you saying that subclassing computeLogicalWidth() would still mean that >>> I'm computing the margins at the initial calculation time? >> >> You'd be computing them whenever the ruby run's layout changed. The problem >> with that is if you're setting margins based off surrounding content, you're >> not going to get a layout just because your surroundings changed. > > Probably a novice question but are there mechanisms or ways to trigger > re-computing of the ruby's layout when the surrounding text has changed? In this case, you really don't need to re-layout the RenderRubyRun itself. You just need to possibly change its margins. I think hooking into findNextLineBreak is the easiest way to do this, since you can see your surroundings and figure out what it is you'd be overlapping and how much room you have on the line. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby Text Enhancements
On Sep 27, 2010, at 3:40 PM, Eric Mader wrote: > > Are you saying that subclassing computeLogicalWidth() would still mean that > I'm computing the margins at the initial calculation time? > You'd be computing them whenever the ruby run's layout changed. The problem with that is if you're setting margins based off surrounding content, you're not going to get a layout just because your surroundings changed. >> It just doesn't seem like you can deal with all the corner cases without >> integrating right into line layout. I don't see how else you can know if >> you have adequate available space to actually overhang without knowing what >> you've seen so far on the line and how much space you have left on the line. > > This would require special-casing the ruby blocks in line layout code, right? > I was trying to avoid this, hoping that I could just extend the existing ruby > objects. > Right. It's kind of a minor miracle that Ruby has gotten this far without having to do this though. :) This method makes several assumptions that I'm not 100% sure are always safe: * That a RenderRuby object holds only 1 RenderRubyRun object. >> >> I believe you can have multiple RenderRubyRuns inside a single RenderRuby. >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element >> >> "The ruby element allows one or more spans of phrasing content to be marked >> with ruby annotations." >> * That the text for the ruby text and ruby base are always the direct child of the RenderRubyText and RenderRubyBase object. >> >> I doubt that's a valid assumption. I assume that you can have a content >> tree of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if >> you put in some and some . Anyway, I think you could just ask for >> the width() of the rubyText() and rubyBase() objects themselves rather than >> drilling down into their subtrees. > > I couldn't figure out how to ask the RenderRubyText and RenderRubyRun objects > for their width. They don't support the width() method. What method should I > call? > They should. They are RenderBlocks, so they should have width() methods. You may have just been getting bad results because you hooked in before the width was computed. That's why computeLogicalWidth subclassing would work better for you. Let the base class set up the margins and width, and then you override. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Ruby Text Enhancements
On Sep 24, 2010, at 6:56 PM, Eric Mader wrote:
>> I have prototyped something that seems to more-or-less work. Here's what I
>> did:
>>
>> 1) Changed RenderRubyRun to subclass these methods:
>> virtual int marginTop() const;
>> virtual int marginBottom() const;
>> virtual int marginLeft() const;
>> virtual int marginRight() const;
>>
>>
>> 2) added these members to RenderRubyRun:
>> mutable bool m_haveHorizontalMargins;
>> mutable int m_leftMargin;
>> mutable int m_rightMargin;
>>
>> 3) Added this private method to RenderRubyRun:
>> void getHorizontalMargins() const;
>>
>> 4) Here's what marginLeft() and MarginRight() look like:
>> int RenderRubyRun::marginLeft() const
>> {
>> getHorizontalMargins();
>>
>> return m_leftMargin;
>> }
>>
>> int RenderRubyRun::marginRight() const
>> {
>> getHorizontalMargins();
>>
>> return m_rightMargin;
>> }
>>
>> And here's getHorizontalMargins():
>> void RenderRubyRun::getHorizontalMargins() const
>> {
>> if (m_haveHorizontalMargins) {
>> return;
>> }
>>
>> RenderText* rubyRenderText = static_cast
>> (rubyText()->firstChild());
>> RenderText* baseRenderText = static_cast
>> (rubyBase()->firstChild());
>> int rubyLength = rubyRenderText->firstTextBox()->width();
>> int baseLength = baseRenderText->firstTextBox()->width();
>> int leftMargin = RenderBlock::marginLeft();
>> int rightMargin = RenderBlock::marginRight();
>>
>> if (baseLength < rubyLength) {
>> RenderObject* prevSibling = parent()->previousSibling();
>> RenderObject* nextSibling = parent()->nextSibling();
>> bool prevIsText = prevSibling && prevSibling->isText();
>> bool nextIsText = nextSibling && nextSibling->isText();
>>
>> // FIXME: handle odd difference?
>> if (prevIsText)
>> leftMargin += (baseLength - rubyLength) / 2;
>>
>> if (nextIsText)
>> rightMargin += (baseLength - rubyLength) / 2;
>> }
>>
>> m_leftMargin = leftMargin;
>> m_rightMargin = rightMargin;
>> m_haveHorizontalMargins = true;
>>
>> }
>>
It would probably be simpler to just subclass computeLogicalWidth (recently
renamed from calcWidth) and modify the m_marginLeft and m_marginRight variables
after calling the base class method. Then you don't have to add any new member
variables.
The big problem with building the overhang into margins at the initial
calculation time, though, is that you may not get a relayout when objects
around you change, so you won't get an opportunity to adjust your margins when
that happens. Your margins are also computed before you've even know what's
going on the line, so it could be really tricky to have all the information you
need.
It just doesn't seem like you can deal with all the corner cases without
integrating right into line layout. I don't see how else you can know if you
have adequate available space to actually overhang without knowing what you've
seen so far on the line and how much space you have left on the line.
>> This method makes several assumptions that I'm not 100% sure are always safe:
>> * That a RenderRuby object holds only 1 RenderRubyRun object.
I believe you can have multiple RenderRubyRuns inside a single RenderRuby.
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element
"The ruby element allows one or more spans of phrasing content to be marked
with ruby annotations."
>> * That the text for the ruby text and ruby base are always the direct child
>> of the RenderRubyText and RenderRubyBase object.
I doubt that's a valid assumption. I assume that you can have a content tree
of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if you put in
some and some . Anyway, I think you could just ask for the width() of
the rubyText() and rubyBase() objects themselves rather than drilling down into
their subtrees.
>> * That the neighboring text is always a direct sibling of the RenderRuby
>> object.
>>
Not a valid assumption. You could have empty spans etc.
>> One enhancement I know is needed is to look at successive neighboring
>> objects to make sure that there's enough text there that the overhanging
>> part of the ruby text doesn't overshoot the neighbor(s) as well and bump
>> into something it can't overlap.
>>
>> Does this general approach look right?
This is a tough problem. It seems like you have to get involved in the line
layout code e.g., findNextLineBreak in order to really do the right thing.
findNextLineBreak uses an iterator that walks the objects, so it's easier to
tell what text came before you and what text comes after you. You can also
tell whether or not that text will even fit on the line and possibly do the
margin hacking there.
You may not want to overhang either if the surrounding text has a higher
ascent, since I assume you don't w
Re: [webkit-dev] Ruby Text Enhancements
On Sep 21, 2010, at 2:52 AM, Roland Steiner wrote: > > > > We'd probably need to add a new value to that property if Ruby is supposed to > be skipped. > > Ergh Looking at it, I'm not sure that's a good proposal at all - at least > it has still lots to address (it doesn't address list bullets, or > :before/:after generated content, for one). I think that the best approach > for ruby would be to view the whole ruby run (i.e., base and text combined) > as the main object for text-decoration, and not the base and text > individually. That is: > > .) underline: line painted below the base only, over the width of base and > text (but excluding any overhangs!) > .) overline: overline painted above the text, same as above - note that the > line width doesn't (!) change > .) line-through: either just the base is decorated, or both base and text. I > can see arguments for either way, although I think painting a line-through > through the text may overly obscure it, since it's quite small - note that > the line width for the ruby text would need to be different in this case as > well, which in turn probably means amending the spec. > .) blink: all blinks ;) > > This however means that a rule for would need to affect the ruby text > separately, independent of the decoration of the whole thing (which IMHO > would be a good thing anyway). Yeah the main point I was trying to make with text-decoration is that in the strict mode model it's the element with text-decoration on it that draws the line. So right now if you have: [some ruby] It's the line boxes for the element that draw a line, and it just cuts through the ruby no matter where the ruby happens to be (just as it might cut through any other objects like images that might have a different vertical alignment). We have no concept of making that line skip elements or do something different, so it's a fair bit of work to customize the behavior. Even more annoying is that text-decoration has two completely different code paths for quirks vs. strict mode. In quirks mode, the underlines are drawn by the elements themselves (so e.g., you get no underlines under images in quirks mode), and so customizing the line drawing behavior will be easier to do in quirks mode. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby Text Enhancements
On Sep 17, 2010, at 8:07 PM, Eric Mader wrote: > Hi, > > I'm working on making the following enhancements to Ruby Text: > > 1) Implement the behavior of ruby-overhang:auto > > 2) implement the behavior of ruby-line-stacking:exclude-ruby > > 3) Add some Mac OS specific character properties to the ruby text > > 4) Turn off the underline when the ruby text is in a link > > I've looked at the code enough to know that the layout or ruby text is done > by the normal block stacking in BlockLayout. I'm guessing that I can do at > lest the first two tasks by changing the RenderRuby code to report a > different width and / or height for the ruby block. Does this seem like the > right way to do what I want? > > Assuming for the moment that it is, I have some questions: > > 1) What methods should I subclass to report the adjusted width and height? > I'm very hazy on the Ruby implementation. I believe it makes an inline-block with two block children vertically stacked, and then it uses text-align:center to center the ruby base. If so, this behavior has to be preserved when the ruby text is wider than the base. I think a reasonable way to implement overhang therefore would be with negative margins applied to the ruby run. This way the correct layout of the Ruby object is preserved, and the surrounding text will just naturally get pushed inside the Ruby object to overlap it. Basically you can compare the delta in width between the base and the text and then apply margins to either side of the ruby run based off how you want to overhang. > 2) If the ruby text is wider than the ruby base and I report the width of the > base as the width of the whole block will some of the ruby text get clipped, > or will it all still draw? > It would all still draw as long as you set up overflow correctly. You can look for addLayoutOverflow methods. I think you may be able to use negative margins for overhang though without altering your reported width. > 3) Ruby text is only allowed to overhang the base in some cases. To know when > it's OK, I'll need to examine the neighboring text. Can I always find the > neighboring text by walking the render tree? > This is going to be tricky. You basically want to walk the line box tree rather than the renderobject tree and then look at surrounding text. > About turning off the underline if the ruby is in a link: I've looked at the > styles and tried adding code to change the parts that I think relate to this, > but haven't found anything that makes a difference. It's also occurred to me > that I might be able to do this by writing a rule in > WebCore/css/html.css, but I can't figure out exactly what the rule > would look like. I tried adding "text-decoration: none" to the "ruby > rt" > section, but that doesn't do it. > > (at first, I thought that is was probably overkill, but now I think that > turning text-decoration off for all ruby text is probably right.) There is no way to do this. The closest I see is: http://dev.w3.org/csswg/css3-text/#text-decoration-skip This is not implemented in WebKit yet. We'd probably need to add a new value to that property if Ruby is supposed to be skipped. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] attached()
On Sep 9, 2010, at 12:17 PM, Eric Seidel wrote: > > I'm not sure what you mean. You mean that the change in my patch to > run the lazyAttach logic from insertedIntoDocument may cause > additional style recalcs? The new element needs style calculated > regardless. Marking an element with childNeedsStyleRecalc doesn't > recalculate the style for that object to my knowledge. Oh I thought lazyAttach was actually marking nodes as needing a full style recalc. If it's not then I guess that's fine. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] attached()
On Sep 9, 2010, at 2:00 AM, Eric Seidel wrote: > > Instead, we could change all elements to mark themselves (and their > parents) as needing style recalc during insertedIntoDocument(), > effectively "attaching/lazyAttaching". lazyAttach is poorly implemented right now, since it is relying on style recalculation to trigger the attachment when it should have used a new timer. Right now because it is latching onto the style recalc timer and tree it is wasting time doing recalc styles on all of the ancestors of any elements that need attaching. That's just bad. This means the normal attach() process performs better (and is presumably still used by the parser). We should fix lazyAttach to use its own timer and tree walk independent of recalcStyle that just calls attach() instead on children that need it. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Arena is crufty?
Please let's not add another client of Arena though. That will just make it harder to remove, and I highly doubt you're getting any real performance gain from using it. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Arena is crufty?
On Sep 1, 2010, at 7:07 PM, Maciej Stachowiak wrote: > > On Sep 1, 2010, at 7:04 PM, David Hyatt wrote: > >> We should just kill Arena and remove it and RenderArena both. > > Wasn't it still a measurable slowdown last time we tried that? > Not enough to matter. We could easily make up the difference. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Arena is crufty?
We should just kill Arena and remove it and RenderArena both. dave On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote: > > Ken's PODRedBlackTree patch has made me go back and take a closer look at > WebKit's Arena "class". Turns out it's not a class at all, just some structs > and macros. That seems very un-WebKit-like to me. Ken's patch also has a > PODArena class, which uses Arena in its implementation. Sam suggests that > PODRedBlackTree should really go into WTF, which means PODArena and Arena > would need to go there as well. > > It seems like Arena really needs to be brought into the 21st century and made > a proper class. Maybe now is the right time to: > > 1) Make Arena a class > > 2) Integrate Ken's PODArena functionality into this new Arena class (or maybe > just make Ken's PODArena the new Arena class). > > 3) Move the new Arena class to WTF > > 4) Put PODRedBlackTree in WTF > > It looks like RenderArena is currently the only client of Arena.h, so this > change shouldn't be too hard. Of course, looking at RenderArena, it's a > little odd, too. It is not renderer specific at all. It's just an Arena that > recycles freed objects. Maybe we should move that functionality into the new > Arena class. But RenderArena is used all over the place, so maybe that's > going one step too far down this road? > > - > ~Chris > cmar...@apple.com > > > > > ___ > 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] Color Management
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote: > 2010/9/1 Alexey Proskuryakov : >> >> 01.09.2010, в 08:31, Igor Trindade Oliveira написал(а): >> >>> a) use an external dependency(littlecms for example); >>> >>> b) write from scratch all the ICC Profile specification; >>> >>> What do you guys think what the best approach? >> >> >> I think that the first question to answer is why a CMS implementation is >> needed in WebKit at all. It's normally the job of a drawing library to >> perform the conversion behind the scenes. >> >> For example, one can specify a color space when drawing with CoreGraphics >> (as used by Mac and Windows Safari). If some platforms don't have such >> support, deciding what to do with colors should be left to platform-specific >> code in WebKit anyway. >> >> This is what already happens with images that have color profiles embedded, >> for example. >> >> - WBR, Alexey Proskuryakov >> >> > > Hi, > > in Qt and Cairo Graphics side does not exist internally any color > management system normally the application that needs it uses a > external dependency like littlecms, this approach is used by Krita[1] > for example. So if the graphics api does not have any support to color > management the fallback could be done to WebKit CMS. > > Other use case could be used by icc support in css3. In the last > draft, css3 drops color-profile property due to a lack of > implementation [2][3]. It seems like this support would just be behind the GraphicsContext abstraction (which is already colorspace-aware). I don't see why you'd need code above GraphicsContext. Even color-profile in CSS should ultimately just pass the contents of the color profile to GraphicsContext. For example CoreGraphics supports CGColorSpaceCreateWithICCProfile, so I'd just expect GraphicsContext to take the ICC profile data and let the platform decide what to do with it. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Aug 31, 2010, at 10:36 AM, Chris Marrin wrote: > Or should we get rid of Vector3, added the functionality it needs to > FloatPoint3D and use that? Ken Russell already has plans to do add the > functions to FloatPoint3D, so I would vote for that. I would vote for this. I don't think the geometry classes should move to wtf. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is XBL?
The code can be removed. dave On Aug 25, 2010, at 12:17 PM, Adam Barth wrote: > There seem to be a bunch of files missing too. For example, I can't > find XBLDocument or XMLBindingsManager. > > I don't mean to hate on XBL, I just started looking at it when > deploying adoptPtr and was surprised by what I found, that's all. > > Adam > > > On Wed, Aug 25, 2010 at 10:13 AM, Darin Adler wrote: >> I think Hyatt should comment on this before we decide. I do think that >> removing the code would be good but he may have some additional insight. >> >>-- Darin >> >> ___ >> 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] Can someone explain tx/ty?
On Aug 23, 2010, at 12:11 PM, David Hyatt wrote: > >> (hopefully less verbose, but you get the idea). tx, ty could be named >> parentOffsetFromLayerCoordinates or something. This seems to be the intent >> of the names - that x,y is a point and tx, ty is a translation. But this >> doesn't work in point/size logic. You repeatedly add x(), y() to tx, ty to >> get a new tx, ty. But that means you're adding a point to a size and >> expecting to get a new size - but that's not how it works. >> > > I think a helper method that does the right thing solves this problem (rather > than having to flip what x/y and tx/ty mean just to do some math operation). > > dave Just to clarify, if tx/ty turned into an IntSize offset, I think you could just add a helper method like .asOffset() to IntPoint to solve this particular problem. Instead of tx += x(); ty += y(); You could write: offset += location().asOffset(); I'd also have no objection to just building that right into RenderBox... offset += locationOffset(); dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can someone explain tx/ty?
On Aug 23, 2010, at 4:33 AM, Maciej Stachowiak wrote: > > > - tx, ty are the origin of the parent's coordinate system relative to the > origin for its layer. When a layer paints, it establishes a CTM such that its > own origin is 0, 0 (I think). > They are relative to a painting root, which will basically either be the document or a compositing layer. > The more obvious way, given the variable names, would be to make x(), y() an > IntPoint, with a name like originInParentCoordinates() It already is an IntPoint internally. There's already a method to access it as a point. IntPoint location() const > (hopefully less verbose, but you get the idea). tx, ty could be named > parentOffsetFromLayerCoordinates or something. This seems to be the intent of > the names - that x,y is a point and tx, ty is a translation. But this doesn't > work in point/size logic. You repeatedly add x(), y() to tx, ty to get a new > tx, ty. But that means you're adding a point to a size and expecting to get a > new size - but that's not how it works. > I think a helper method that does the right thing solves this problem (rather than having to flip what x/y and tx/ty mean just to do some math operation). dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
The changes to ImageBuffer have landed. Here is what port authors need to know: Image* image() on ImageBuffer is gone. It has been replaced with: PassRefPtr copyImage() This function should always simply copy the image. It is used in any place where you want to get a snapshot of the ImageBuffer and not be broken if the ImageBuffer subsequently changes. For drawing, callers should now use drawImageBuffer on GraphicsContext instead of drawImage. drawImageBuffer internally just turns around and calls a draw function on ImageBuffer. clipToImageBuffer now also turns around and calls clip on the ImageBuffer. void clip(GraphicsContext*, const FloatRect&) const; // The draw method draws the contents of the buffer without copying it. void draw(GraphicsContext*, ColorSpace styleColorSpace, const FloatRect& destRect, const FloatRect& srcRect = FloatRect(0, 0, -1, -1), CompositeOperator = CompositeSourceOver, bool useLowQualityScale = false); void drawPattern(GraphicsContext*, const FloatRect& srcRect, const AffineTransform& patternTransform, const FloatPoint& phase, ColorSpace styleColorSpace, CompositeOperator, const FloatRect& destRect); I've made sure the above functions are implemented in the various ports, although the Skia and Cairo implementations currently draw by copying the image and then just calling drawImage. I've left it up to those ports to fix this issue (the current behavior is the same on those platforms as it was before my patch). There is a temporary method implemented by all ports called: bool drawsUsingCopy() const; // If the image buffer has to render using a copied image, it will return true. This method only exists right now because some of the ports are still copying. Once everyone has switched over to drawing the image buffer without making copies, then I can remove this method from the interface. HTMLCanvasElement is using it in order to cache a copy of the image for repeated drawing of a static canvas, so that the "copying" platforms don't suffer a performance degradation from my changes. Feel free to ping me on IRC or in email if you have any questions about this change. Thanks, Dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ANGLE
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote: > On Sat, Aug 14, 2010 at 4:21 PM, wrote: > > > > On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote: > > > >> Hi, > >> > >> ANGLE looks like a graphics helper library. Why it is placed in the root > >> WebKit directory? Perhaps WebCore/platform/graphics or some kind of > >> /3rparty directory would be better, wouldn't it? > > > > ANGLE is a library from Google (http://code.google.com/p/angleproject/) > > which is mirrored in the WebKit tree for convenience. Since it's not > > actually part of WebKit, it was felt that keeping it the root was best. > > > > /3rdparty/ANGLE would be more straightforward in my opinion. Having this > in the root is deceptive, personally I did not realized that it is a > mirrored tree before your explantation. > > > I'm surprised it isn't pulled as a .zip like the other third-party libraries > (like icu, libxml, etc.) through the update-webkit script. Agreed. This is how I'd expect it to work. I don't understand why it's checked into WebKit. Now we're even building it as part of the build process, which I just don't understand. Are we having to alter the ANGLE source in the WebKit tree? That's the only reason I can think of why we would have a copy of the source checked in like this. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
Yeah I'll get it posted soon in a bug. I need to make get/PutImageData work first. :) dave On Aug 11, 2010, at 12:35 PM, Ariya Hidayat wrote: >> http://themaninblue.com/experiment/AnimationBenchmark/canvas/ >> >> Jumped from 37fps to 85fps. > > Do you post the patch somewhere? Would be lovely to try this on QtWebKit... > > > > -- > Ariya Hidayat > http://www.linkedin.com/in/ariyahidayat > ___ > 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] Canvas performance and memory usage
On Aug 10, 2010, at 2:49 PM, David Hyatt wrote: > Yeah, I think an even better way of abstracting it might be to make > ImageBuffer:drawIntoContext(GraphicsContext*, ...). I think that would be > simpler for people implementing something special. If we did that, then the > image() accessor on ImageBuffer could probably just always be a deep copy (or > copy-on-write). > > Getting rid of the graphicsContext->drawImage(imageBuffer->image()) > pattern would definitely be good though. > > I'm just really curious about the performance of canvas and whether it's > better to have slower get/PutImageData or faster rendering otherwise. It > all comes down to how people are using canvas. I suspect that > get/PutImageData are really really popular. I implemented ImageBuffer::drawIntoContext on Mac, and I switched the implementation of ImageBuffer to dynamically swap to a CGLayer (throwing away the bitmap context) if it can do so. Preliminary tests look very very good. This benchmark for example: http://themaninblue.com/experiment/AnimationBenchmark/canvas/ Jumped from 37fps to 85fps. I'll need to see what happens with intensive get/PutImageData examples though before I declare victory, but it definitely looks like slowing down get/PutImageData is worth it if we can get performance gains like this! dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
On Aug 10, 2010, at 2:38 PM, Stephen White wrote: > On Mon, Aug 9, 2010 at 6:17 PM, David Hyatt wrote: > There are other cases as well where you want a copy. Patterns are another > example. For example you can create a pattern from another canvas, and I > don't think it's supposed to be live if that other canvas later changes. > There are examples in SVG as well where patterns are used and I am pretty > sure a copy is the desired behavior. > > I don't think it's as simple as saying "image()" should never copy. > > I spent some time thinking about this from a CG perspective, and I couldn't > really come up with a good solution. We use a bitmap context for efficient > pixel access for get/putImageData. Any platform that wants these functions > to be efficient has to keep the pixels easily obtainable. This means, for > example, that we can't produce a live image using CGLayers. Looking at Qt, > the only current platform to return a "live" image to canvas for rendering, > it looks like they made this tradeoff, i.e., it looks to me like > get/putImageData are slower than other platforms. (The get is having to call > toImage() on a pixmap and then has to convert to obtain a good representation > of the data for a QImage). The put has to render the changes into the pixmap. > > I tried renaming the two methods (image() and imageForRendering()) to > copiedImage and liveImage, and ended up with about an 80/20 split at the call > sites between the two. It looked really ugly to me, since in nearly every > case the "liveImage" was just being used to paint the current contents of the > ImageBuffer, i.e., it was just being passed to drawImage. The copiedImage > was typically passed to somebody who needed to retain it for later rendering, > e.g., a pattern. > > So to sum up, the call sites want two things: > > (1) To render the current contents of the image buffer efficiently. > > Would it make sense to add a GraphicsContext::drawImageBuffer(ImageBuffer*, > ...) call for this use case? Then the details of how the image is actually > extracted (or not) could be kept down in the platform-specific layers. I > don't know if this entirely helps the problem under discussion, but I ran > into it in another context and it seemed like it would be useful. Yeah, I think an even better way of abstracting it might be to make ImageBuffer:drawIntoContext(GraphicsContext*, ...). I think that would be simpler for people implementing something special. If we did that, then the image() accessor on ImageBuffer could probably just always be a deep copy (or copy-on-write). Getting rid of the graphicsContext->drawImage(imageBuffer->image()) pattern would definitely be good though. I'm just really curious about the performance of canvas and whether it's better to have slower get/PutImageData or faster rendering otherwise. It all comes down to how people are using canvas. I suspect that get/PutImageData are really really popular. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
There are other cases as well where you want a copy. Patterns are another example. For example you can create a pattern from another canvas, and I don't think it's supposed to be live if that other canvas later changes. There are examples in SVG as well where patterns are used and I am pretty sure a copy is the desired behavior. I don't think it's as simple as saying "image()" should never copy. I spent some time thinking about this from a CG perspective, and I couldn't really come up with a good solution. We use a bitmap context for efficient pixel access for get/putImageData. Any platform that wants these functions to be efficient has to keep the pixels easily obtainable. This means, for example, that we can't produce a live image using CGLayers. Looking at Qt, the only current platform to return a "live" image to canvas for rendering, it looks like they made this tradeoff, i.e., it looks to me like get/putImageData are slower than other platforms. (The get is having to call toImage() on a pixmap and then has to convert to obtain a good representation of the data for a QImage). The put has to render the changes into the pixmap. I tried renaming the two methods (image() and imageForRendering()) to copiedImage and liveImage, and ended up with about an 80/20 split at the call sites between the two. It looked really ugly to me, since in nearly every case the "liveImage" was just being used to paint the current contents of the ImageBuffer, i.e., it was just being passed to drawImage. The copiedImage was typically passed to somebody who needed to retain it for later rendering, e.g., a pattern. So to sum up, the call sites want two things: (1) To render the current contents of the image buffer efficiently. (2) To obtain a copied image that is independent of the image buffer that is typically retained by someone else. And the current implementations of image()/imageForRendering() do three things: (1) Make a copy of the image buffer into an Image (e.g., Skia). (2) Make an Image that is a live representation of the Image buffer contents (e.g., Qt using imageForRendering). (3) Make a copy-on-write image wrapper (e.g., CG). Assuming the copy-on-write stuff in CG is actually working (and I suspect that it is), then it's actually a pretty good solution. You don't copy to do throwaway drawing. Pixel access is efficient using get/PutImageData. There's no need to distinguish between copied images vs. live, with the caveat that the cached image has to be cleared (only an issue for canvas, since nobody else does continual drawing to ImageBuffers). Anyway I'm open to suggestions here. :) As for removing the ImageBuffer completely, I don't think you can get away with that. The canvas buffer's size does not necessarily match the size into which it is drawn. You need to be able to get to the image pixels of a possibly larger (or smaller) buffer. You also have to be able to draw the contents of one canvas into another canvas, so you have to be able to treat the canvas as an image. Again that means being able to get to the contents of the canvas itself as a separate buffer/image. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
I'm confused why a special method is needed though. Can't image() just avoid the full copy? Given how we use image() in WebKit, I don't think there's any reason to be concerned if image() continues to reflect the contents of the ImageBuffer. I think we should just switch to that model for the CG port also anyway, since I'm unconvinced we're truly avoiding a copy, and return an image with a custom data provider that feeds the current contents of the ImageBuffer to the image. dave (hy...@apple.com) On Aug 3, 2010, at 8:55 PM, Martin Robinson wrote: > Resent from the proper address: > > On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson > wrote: >>> I notice that Qt added imageForRendering() and felt they could not use >>> image() for some reason. I'd be curious if a Qt expert could weigh in on >>> that, since maybe with a redesign a separate call would not be needed. > > I'm not a Qt expert, but just based on a quick look, it seems that > imageForRendering avoids the full QPixmap copy. Christophe, > when you open a bug for this issue, please CC me, as I have a > small patch in my tree which has the same imageForRendering > pecialization, but for Cairo. > > Martin > ___ > 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] Canvas performance and memory usage
This would probably have to be verified, but I believe CG uses copy-on-write semantics when creating an image from a bitmap context. Therefore I suspect this is not a performance problem with CG just because of smarts in the underlying CG implementation. Basically image() is a "cheap" call for CG, and creating/destroying images over and over when frequent drawing happens is not expensive. However I'm not 100% sure about this. I think the fact that the image has to be manually cleared from the ImageBuffer is part of the problem. I think we should redesign ImageBuffer::image() so that every time it's called you can guarantee that you're getting an accurate reflection of the contents of the image buffer. I notice that Qt added imageForRendering() and felt they could not use image() for some reason. I'd be curious if a Qt expert could weigh in on that, since maybe with a redesign a separate call would not be needed. Here's a basic suggestion for how to improve this: (1) Make sure your port does a lightweight wrapping of the ImageBuffer into an Image and does not do a copy. It's debatable whether this Image really even needs to be cached if the creation operation is really lightweight. I think people copied the CG implementation I wrote where I wasn't 100% sure if I needed to cache or not, and that has created some of the confusion. (2) If anyone accesses the GraphicsContext of an ImageBuffer and we do cache the Image, maybe just assume they're going to draw and clear out the image. Anyway, I'd definitely file a bug. dave (hy...@apple.com) On Aug 3, 2010, at 3:20 PM, Christophe Public wrote: > Hi, > > There is a performance hit when using HTML canvas when using ImageBufferCairo: > > - As soon as something is rendered in the canvas, the > HTMLCanvasElement::willDraw method is called which in turn calls clearImage > on the imageBuffer if one is already present. > - When the render tree is traversed (HTMLCanvasElement::paint gets called), > the image containing the canvas is drawn using GraphicsContext::drawImage. > Unfortunately, ImageBuffer::image() (in BufferImageCairo.cpp) allocates a new > surface, and copies the image surface into it. When very frequent updates are > done in the canvas, this double buffering causes significant performance > degradation that worsens with large canvas sizes. In addition, the extra > memory consumption can become quite expensive especially on embedded devices. > > Can anybody explain why this double buffering is necessary for ImageBuffer > specifically for the Cairo port? > > We are looking at disabling the double buffering at least for the canvas > because of both performance and memory issues. It would also be nice to > disable it for images as well but we would like to understand why in the > first place it was added. Note that a code comment states "This seems silly, > but is the way the CG port works: image() is intended to be used only when > rendering is complete." > > Any suggestion on how to fix this issue is welcome. If it is considered a > bug, then I will create a bug as well to keep track of it. > > Regards, > Christophe > > ___ > 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] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak wrote: > > The reason for these is historical. Originally, we didn't use a separate > vendor prefix for WebKit, just -khtml. Later we changed to -apple. That's not quite right. Originally we just had -khtml- for CSS extensions, and then we used -apple- for features that we were Apple-specific, i.e., that we knew nobody else would care about. Those features include Dashboard regions and Safari RSS line clamping). Eventually we just decided to merge both into a common prefix, but we wanted to keep the old property names working for compatibility. It was convenient to just map both to -webkit- rather than actually checking the specific property names and only supporting either -khtml- or -apple-. My recommendation would be as follows: (1) Drop support for -khtml- completely. (2) Continue to support -apple- for -apple-dashboard-region and -apple-line-clamp only. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should Table Cell (TD) children inherit height?
It's quirks mode behavior that doesn't follow the standard (and is just for legacy compatibility). You can add to the top of the test case to see the correct behavior according to the standards, which is that percentage heights resolve to auto if they are computed relative to an auto height containing block. dave On Jun 29, 2010, at 9:29 AM, Fady Samuel wrote: > > > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
I filed https://bugs.webkit.org/show_bug.cgi?id=40800 to track this issue. I think we can take further discussion to the bug. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Jun 17, 2010, at 4:24 PM, Matt 'Murph' Finnicum wrote: > On Thu, Jun 17, 2010 at 4:19 PM, David Hyatt wrote: > On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: > > > David, it's bit more than annoying, it's fragmenting memory for no > > good. In the long run on systems will small memory it does make a > > difference :-/ > > > > I'd like to see some option, maybe compile-time, to strip these > > useless whitespaces. > > > > As Alexey points out, this is a compatibility issue though. People write > code assuming the whitespace nodes are there. If you remove them, you'll see > Web site breakage. > > dave > (hy...@apple.com) > > > Do people write code assuming the content of the whitespace nodes? That seems > very unlikely to me. If not, we could collapse them and be much more > efficient about things (such as a simple flag in their parent node that > represents their existence) > They absolutely do. Way back in the original KHTML, these nodes were omitted from the DOM, and we had compatibility bugs in WebCore caused by the absence of those nodes. One of the earliest bits of work I did on WebCore (8 yrs ago) was to add those whitespace nodes back into the DOM. The other issue you run into is that at any time someone can change the style of an element to have white-space: pre in CSS. If you don't retain information about the white-space, then you'll have a correctness issue when the white-space style changes and suddenly requires you to preserve the spaces. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Jun 17, 2010, at 4:07 PM, Eric Seidel wrote: > A does not follow from B in that sentence, that current memory > fragmentation means we need to strip whitespace nodes. > Yeah exactly. Let's see some measurements that show the presence of these nodes are a real problem. > It would also be possible to create a special shared "\n" text node, > and have some sort of Copy On Write behavior. Again, more complexity. > Not sure if the complexity would be worth the perf win. > There might be interesting tricks around this idea yeah. Basically you want the common case of never really looking at the DOM from JS to result in efficient performance/memory use. If walking the DOM then results in the creation of a more heavyweight whitespace Node, that would be fine I think. The idea of trying to fold the information into Element is an interesting one. Again I think we'd need measurements to see how much of a gain we'd typically get if we did this just for newlines for example, or if we'd need an optimization that extended to arbitrary whitespace sequences. I tend to think the latter would be required (since cleanly indented HTML will have newlines and tabs and spaces for indentation in between elements). I'm not particularly interested in a "break-the-web" mode that strips out those Nodes completely by default, since (a) breaking compatibility is bad and (b) nobody has shown me any evidence that these extra nodes are a problem on mobile devices. An optimization that reduces memory use while preserving the correct behavior is much more appealing to me. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: > David, it's bit more than annoying, it's fragmenting memory for no > good. In the long run on systems will small memory it does make a > difference :-/ > > I'd like to see some option, maybe compile-time, to strip these > useless whitespaces. > As Alexey points out, this is a compatibility issue though. People write code assuming the whitespace nodes are there. If you remove them, you'll see Web site breakage. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
Although it's annoying that these extra whitespace nodes are in the DOM, we do at least make sure not to create renderers for them most of the time. dave On Jun 17, 2010, at 1:37 PM, Alexey Proskuryakov wrote: > > 17.06.2010, в 9:53, Andreas Delmelle написал(а): > >> If WebKit chooses, for example, to ignore character events from the parser >> in nodes where logically it doesn't make sense to have stray characters > > > That would break e.g. Web sites where JS accesses DOM in ways such as > node.firstChild.nextSibling, or node.childNodes[3]. We've previously seen > similar breakage happen after changing WebCore parsing code. > > - WBR, Alexey Proskuryakov > > ___ > 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] Why so many text nodes in the DOM? (especially ones with just whitespace)
Whitespace nodes most commonly occur between elements, so they can't be coalesced. dave On Jun 14, 2010, at 7:00 PM, Matt 'Murph' Finnicum wrote: > Why are there so many Text nodes in the DOM? I had a look at the initial DOM > tree from rendering slashdot, and there are 1959 Text nodes. Of those 1959, > 1246 were whitespace-only nodes. > > Does there need to be this many nodes? Why can't whitespace be combined with > the nodes next to it? > > Thanks, > --Murph > ___ > 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] HTML5 tokenizer landing soon
On Jun 14, 2010, at 4:05 PM, Adam Barth wrote: > On Mon, Jun 14, 2010 at 1:53 PM, David Hyatt wrote: >> On Jun 14, 2010, at 3:48 PM, Adam Barth wrote: >>> We ended up using the same algorithm as the old tokenizer to manage >>> insertion points, however, we moved all the work into a separate >>> InputStream data structure: >>> >>> http://trac.webkit.org/browser/trunk/WebCore/html/HTML5DocumentParser.h#L75 >>> >>> The old code was actually pretty clever once I figured out what it was >>> doing. We're considering moving InputStream into its own file instead >>> of keeping it as an inner class of the document parser. >> >> If you're talking about the segmented string stuff, I added that to the >> existing tokenizer. :) > > Yeah, well, I already knew you were a clever guy. :) In all seriousness, though, those are the kinds of optimizations to make sure to move over. I remember other optimizations we did around quick comparisons, some AtomicString stuff, and the SegmentedString stuff. As long as that moved over, you should see comparable performance I would think. We just need to make sure not to lose that work in the transition (and it sounds like we haven't, so good). dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 tokenizer landing soon
On Jun 14, 2010, at 3:48 PM, Adam Barth wrote: > > We ended up using the same algorithm as the old tokenizer to manage > insertion points, however, we moved all the work into a separate > InputStream data structure: > > http://trac.webkit.org/browser/trunk/WebCore/html/HTML5DocumentParser.h#L75 > > The old code was actually pretty clever once I figured out what it was > doing. We're considering moving InputStream into its own file instead > of keeping it as an inner class of the document parser. > If you're talking about the segmented string stuff, I added that to the existing tokenizer. :) dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 tokenizer landing soon
On Jun 14, 2010, at 2:44 PM, Geoffrey Garen wrote: > >> The old parser was un-touchable for fear of breaking the world. > > Once again, I believe in hackability, but we don't need to rewrite history in > order to justify it. In the past, we have indeed made changes to the old > parser to improve its performance, to good effect. Yeah and most times we touched it to improve performance, we introduced subtle regressions or tripped over nasty edge cases caused by the horrible state of the code and the poor documentation of that code. I think Eric's statement is pretty justified actually. Either you considered the parser un-touchable and just stayed out of it, or you hacked on it, ultimately with good effect, but often with great pain and suffering involved in the regression department just to achieve those improvements. I really do consider the current code to be "barely hackable," so any new code that follows the HTML5 spec (especially one that has a document.write / pending script model that is easier to understand) is a huge win in my book. dave (hy...@aple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 tokenizer landing soon
On Jun 14, 2010, at 2:11 PM, Eric Seidel wrote: > The new parser will certainly be faster than the old, mostly because > it's now hackable. The old parser was un-touchable for fear of > breaking the world. This one is tested, perf-tested, documented and > much better designed. May the optimizing begin! > Better designed is certainly true, given that any design is better than no design. ;) dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
Yes, I got schooled on this days ago, but welcome to the party! ;) dave On Jun 10, 2010, at 6:00 PM, Maciej Stachowiak wrote: > > On Jun 2, 2010, at 1:22 PM, David Hyatt wrote: > >> >> I really don't think hit testing needs to be modified to get what you want. >> You can do a scattershot sampling using multiple candidate points within the >> rect and apply whatever heuristics you want to choose a node. I'm also not >> convinced that we should be complicating core hit testing code in this way, >> since I suspect this is one of those areas where mobile platforms will each >> want to do their own slightly different thing anyway. > > I suspect hit testing a rect against the render tree could be done more > efficiently than scattershot sampling. > > Regards, > Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse wheel event precision
I think for now I'm just going to implement the "minimum line movement of 1" and only do it at the DOM event level. That way if we use the wheel event internally (e.g., for a non-native scrollview implementation) it will still do the right thing. dave On Jun 10, 2010, at 3:01 PM, Peter Kasting wrote: > On Thu, Jun 10, 2010 at 12:26 PM, David Hyatt wrote: > There are Web sites that depend on never scrolling less than 1 wheel delta > line though. So what can we do to get the best of both worlds? > > Can we keep a count of the "total delta not yet sent to the page", and each > time it overflows one wheel delta, send the number of whole wheel deltas and > decrement the counter? Or is that what you were suggesting? > > Unfortunately I don't see how we can simultaneously do this and yet still > send smaller deltas for pages that support them. Perhaps we could split > "scrolling handled by WebKit" and "events sent to script on the page" and use > the fine-grained data in the first and the coarse data in the second? > > PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse wheel event precision
I filed https://bugs.webkit.org/show_bug.cgi?id=40441 to track this issue. dave (hy...@apple.com) On Jun 10, 2010, at 2:26 PM, David Hyatt wrote: > On Jun 10, 2010, at 1:01 PM, Nathan Vander Wilt wrote: > >> On Jun 9, 2010, at 3:51 PM, David Hyatt wrote: >>> On Jun 9, 2010, at 2:25 AM, Andy Estes wrote: >>> >>>> >>>> On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote: >>>> >>>>> What Safari 4 seemed to do was simply provide much greater precision, >>>>> where scrolling half a line simply yielded about 20 units instead of >>>>> being ignored. So the above code would yield integral deltas in browsers >>>>> that only fired events in 3-line increments, but nice fractional deltas >>>>> in WebKit. >>>> >>>> Some sites choose to completely ignore wheel deltas less than 120. On >>>> devices like trackpads where a slow but continuous scrolling gesture tends >>>> to result in a series of small, non-cumulative mousewheel events, the old >>>> behavior caused these gestures to be completely ignored. Yahoo! Mail was >>>> one such site where the small fractional values caused compatibility >>>> issues. >>>> >>>>> What Safari 5's WebKit does is turn one "line" into 4800 (!) units >>>>> instead of 40. >>>> >>>> This could be plausible on a trackpad that scales the wheelDelta based on >>>> gesture velocity, although I'd expect a value of 120 for each tick of a >>>> conventional wheel mouse. As Peter said, if you have a test case where >>>> Safari disagrees with IE on Windows or Chrome on either platform, please >>>> file a bug and we'll investigate. >>> >>> Just a guess, but we might have a regression when dealing with the >>> continuous events generated by a MacBook trackpad. >> >> >> >> Thanks, David. I am testing this with my MacBook trackpad (and attached >> Magic Mouse) in Safari 5. >> >> The following demo will need some massaging to work in IE, but shows the >> problem. Scrolling down so "Line 4." is at the top of the page yields a >> deltaSum of -7200 (!). Interpreted according to MSDN documentation >> (http://msdn.microsoft.com/en-us/library/ms536951(VS.85).aspx) this would >> -60 "increments" (which IIRC are 3-line chunks each) and over seven thousand >> pixels according to Quirksmode's interpretation >> (http://www.quirksmode.org/dom/w3c_events.html, grep wheelDelta) of that >> property. Basically, the wheelDelta values are 60 times what they should be. >> >> On Safari 4, the deltaSum ends up at -120 as expected when scrolling down to >> "Line 4", although quite helpfully the sum can be reached gradually when the >> mouse has smooth scrolling. So I would concur that this a regression of some >> sort. >> >> thanks, >> -natevw > > Having investigated the original bug and its fix that caused this regression, > Safari 4's behavior was correct. The new behavior is broken. A tiny > continuous event in Safari 4 correctly reported values that are smaller than > one line delta, because that's exactly what was supposed to happen in terms > of scrolling. > > There are Web sites that depend on never scrolling less than 1 wheel delta > line though. So what can we do to get the best of both worlds? > > Well, the compatibility fix made all of the continuous deltas way larger than > they should be, just to ensure that you never give a value smaller than 120. > That was not the right thing to do. > > If we can't evangelize the Web sites to fix their broken checks, then a > better fix would be to just ensure that the minimum value of a wheel event is > 120, without performing what amounts to "double multiplication" of the > continuous event. This way we only inflate the continuous delta of the small > scrolling gestures. > > Even then, though, we lose some of the magic of continuous scrolling in that > the small gestures aren't supposed to each result in single line movements. > My top preference would be to evangelize the Web sites, but I would settle > for applying the minimum of 1 wheel line (120) to continuous events. The > current behavior is clearly wrong though and needs to be fixed. > > dave > (hy...@apple.com) > > > > ___ > 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] Mouse wheel event precision
On Jun 10, 2010, at 1:01 PM, Nathan Vander Wilt wrote: > On Jun 9, 2010, at 3:51 PM, David Hyatt wrote: >> On Jun 9, 2010, at 2:25 AM, Andy Estes wrote: >> >>> >>> On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote: >>> >>>> What Safari 4 seemed to do was simply provide much greater precision, >>>> where scrolling half a line simply yielded about 20 units instead of being >>>> ignored. So the above code would yield integral deltas in browsers that >>>> only fired events in 3-line increments, but nice fractional deltas in >>>> WebKit. >>> >>> Some sites choose to completely ignore wheel deltas less than 120. On >>> devices like trackpads where a slow but continuous scrolling gesture tends >>> to result in a series of small, non-cumulative mousewheel events, the old >>> behavior caused these gestures to be completely ignored. Yahoo! Mail was >>> one such site where the small fractional values caused compatibility issues. >>> >>>> What Safari 5's WebKit does is turn one "line" into 4800 (!) units instead >>>> of 40. >>> >>> This could be plausible on a trackpad that scales the wheelDelta based on >>> gesture velocity, although I'd expect a value of 120 for each tick of a >>> conventional wheel mouse. As Peter said, if you have a test case where >>> Safari disagrees with IE on Windows or Chrome on either platform, please >>> file a bug and we'll investigate. >> >> Just a guess, but we might have a regression when dealing with the >> continuous events generated by a MacBook trackpad. > > > > Thanks, David. I am testing this with my MacBook trackpad (and attached Magic > Mouse) in Safari 5. > > The following demo will need some massaging to work in IE, but shows the > problem. Scrolling down so "Line 4." is at the top of the page yields a > deltaSum of -7200 (!). Interpreted according to MSDN documentation > (http://msdn.microsoft.com/en-us/library/ms536951(VS.85).aspx) this would -60 > "increments" (which IIRC are 3-line chunks each) and over seven thousand > pixels according to Quirksmode's interpretation > (http://www.quirksmode.org/dom/w3c_events.html, grep wheelDelta) of that > property. Basically, the wheelDelta values are 60 times what they should be. > > On Safari 4, the deltaSum ends up at -120 as expected when scrolling down to > "Line 4", although quite helpfully the sum can be reached gradually when the > mouse has smooth scrolling. So I would concur that this a regression of some > sort. > > thanks, > -natevw Having investigated the original bug and its fix that caused this regression, Safari 4's behavior was correct. The new behavior is broken. A tiny continuous event in Safari 4 correctly reported values that are smaller than one line delta, because that's exactly what was supposed to happen in terms of scrolling. There are Web sites that depend on never scrolling less than 1 wheel delta line though. So what can we do to get the best of both worlds? Well, the compatibility fix made all of the continuous deltas way larger than they should be, just to ensure that you never give a value smaller than 120. That was not the right thing to do. If we can't evangelize the Web sites to fix their broken checks, then a better fix would be to just ensure that the minimum value of a wheel event is 120, without performing what amounts to "double multiplication" of the continuous event. This way we only inflate the continuous delta of the small scrolling gestures. Even then, though, we lose some of the magic of continuous scrolling in that the small gestures aren't supposed to each result in single line movements. My top preference would be to evangelize the Web sites, but I would settle for applying the minimum of 1 wheel line (120) to continuous events. The current behavior is clearly wrong though and needs to be fixed. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse wheel event precision
On Jun 9, 2010, at 2:25 AM, Andy Estes wrote: > > On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote: > >> What Safari 4 seemed to do was simply provide much greater precision, where >> scrolling half a line simply yielded about 20 units instead of being >> ignored. So the above code would yield integral deltas in browsers that only >> fired events in 3-line increments, but nice fractional deltas in WebKit. > > Some sites choose to completely ignore wheel deltas less than 120. On > devices like trackpads where a slow but continuous scrolling gesture tends to > result in a series of small, non-cumulative mousewheel events, the old > behavior caused these gestures to be completely ignored. Yahoo! Mail was one > such site where the small fractional values caused compatibility issues. > >> What Safari 5's WebKit does is turn one "line" into 4800 (!) units instead >> of 40. > > This could be plausible on a trackpad that scales the wheelDelta based on > gesture velocity, although I'd expect a value of 120 for each tick of a > conventional wheel mouse. As Peter said, if you have a test case where > Safari disagrees with IE on Windows or Chrome on either platform, please file > a bug and we'll investigate. Just a guess, but we might have a regression when dealing with the continuous events generated by a MacBook trackpad. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] problem with css :focus
isFocusedAndActive is asking if your frame is the focused frame and if the
window that contains your frame is also active. I would guess that you are not
setting the state of your frames/windows correctly. If your window is
considered inactive or if your frame is not considered focused, then :focus is
not going to be honored.
dave
(hy...@apple.com)
On Jun 8, 2010, at 3:33 AM, Alex Vazquez wrote:
> Hello list,
>
> We're running a customized build of WebKit (actually a DirectFB port) and we
> are experiencing problems with the css :focus pseudo-class. We use webkit as
> GUI renderer and, when changing the focused element through JavaScript (using
> the focus function), the style associated to the :focus pseudo-class is not
> applied. The attached page is our reduced testcase, it should show two links,
> the first of them focused but it shows two unfocused links:
>
>
>
>
>
>
>
> body {
> color: #f00;
> background-color:#ddd;
> font-size:26px;
> }
>
> div {
> float: left;
> padding: 50px;
> }
>
> a, span {
> float:left;
> display:block;
> clear:both;
> }
>
> a:focus {
> color:#f0f;
> }
>
>
>
>
>
> function init() {
> document.getElementById("uno").focus();
> }
>
>
>
>
>
>
>
>
> http://www.webkit.org/";>WebKit
> http://nightly.webkit.org";>Nightly Builds
>
>
>
>
>
>
>
> The version with this problem is based on r58260 revision while a previously
> one (with nearly the same adapted patches) based in r40084 worked fine. We
> build webkit for an embedded MIPS processor and for x86 too. Both versions
> show the undesired behaviour.
>
> Investigating through the WebKit code, we've found that applying the
> following patch fixes the problem:
>
> --- a/WebCore/css/CSSStyleSelector.cpp2010-06-04 13:35:19.0 +
> +++ b/WebCore/css/CSSStyleSelector.cpp2010-06-04 13:35:35.0 +
> @@ -2428,7 +2428,7 @@
> break;
> }
> case CSSSelector::PseudoFocus:
> -if (e && e->focused() &&
> e->document()->frame()->selection()->isFocusedAndActive())
> +if (e && e->focused())
> return true;
> break;
> case CSSSelector::PseudoHover: {
>
> That line was there since r40084 and it worked so we have some questions
> about the patch:
>
> * Does it have any problem that we have overlooked?
>
> * Can someone with knowledge on the css component explain why the active
> state of the selection is checked in that line? We also try to change that
> check by e->document()->frame()->selection()->isFocused() but it didn't fix
> it.
>
> Kind regards,
>
> --
> Alejandro Vazquez Fente
> ___
> 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] Question about TextBreakIterator usage in RenderText
On Jun 7, 2010, at 4:18 PM, david.le...@nokia.com wrote: > My question is can we optimize this flow somehow? Can we re-use the > TextBreakIterator in the render text class when performing the > RenderText::positionForPoint() function? > That's what the ICU implementation does. I think you just need to fix your implementation to do the same. If you want to push the re-use higher you could probably make cursorMovementIterator cross-platform and then have it contain the static pointer to the reused iterator. Then the existing cursorMovementIterator could be renamed and be called by the new cross-platform function. However you could also just fix your implementation of cursorMovementIterator to reuse the iterator. static bool createdCursorMovementIterator = false; static TextBreakIterator* staticCursorMovementIterator; return setUpIteratorWithRules(createdCursorMovementIterator, staticCursorMovementIterator, kRules, string, length); dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Oh this is purely JS memory use? Hmm ok, my original example wouldn't work, but I still think I could construct an attack. Let me think about it some more. dave On Jun 4, 2010, at 2:31 PM, James Robinson wrote: > How? Visited state information is not stored in the javascript heap (which > is what this object contains information about). > > - James > > On Fri, Jun 4, 2010 at 12:06 PM, David Hyatt wrote: > I'm fairly certain I could construct an attack on :visited history privacy > using this object. > > dave > > On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: > >> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: >> After talking it over with some folks here at Apple, I want to formally >> object to adding the Console.memory extension to the Console object and I >> think we should remove support for Console.profiles as soon as we can. They >> both provide information to users that are not generally useful (beyond the >> "continuous integration/buildbot" use-case which I think is of limited >> utility) and therefore should not be exposed to the web. >> >> Why is the continuous integration/buildbot use-case of limited utility? Or >> are you saying that Console.memory doesn't really support that use-case >> well? I think we want to make it as easy as possible for complex apps (e.g. >> email apps, mapping apps, etc.) to care about and monitor memory use. >> >> While I'm not convinced by the utility argument, I do buy the security >> argument. How would you feel about leaving the code in, but disabling it by >> default? Then it could be enabled by command-line or via a preference. >> >> That said, I'm OK with rolling back for now given that the code was >> committed without this discussion actually coming to a conclusion. >> >> Ojan >> ___ >> 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] On adding 'console.memory' API (and about the whole 'console' object.)
To get more specific, the style allocated for visited state is freed when you're an unvisited link to save memory (lots of memory), but it is not freed if you're visited. So there's a definite memory consumption difference. This memory difference would be magnified and obvious if you made 1 visited links vs. 1 unvisited links. We would have to deliberately consume megabytes more of memory just to prevent this attack if we keep this object in, and I just made the above fix to prevent a more than 4mb memory regression. Therefore I do not think memory use information is safe to expose, and this feature is not something we should be adding. dave (hy...@apple.com) On Jun 4, 2010, at 2:06 PM, David Hyatt wrote: > I'm fairly certain I could construct an attack on :visited history privacy > using this object. > > dave > > On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: > >> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: >> After talking it over with some folks here at Apple, I want to formally >> object to adding the Console.memory extension to the Console object and I >> think we should remove support for Console.profiles as soon as we can. They >> both provide information to users that are not generally useful (beyond the >> "continuous integration/buildbot" use-case which I think is of limited >> utility) and therefore should not be exposed to the web. >> >> Why is the continuous integration/buildbot use-case of limited utility? Or >> are you saying that Console.memory doesn't really support that use-case >> well? I think we want to make it as easy as possible for complex apps (e.g. >> email apps, mapping apps, etc.) to care about and monitor memory use. >> >> While I'm not convinced by the utility argument, I do buy the security >> argument. How would you feel about leaving the code in, but disabling it by >> default? Then it could be enabled by command-line or via a preference. >> >> That said, I'm OK with rolling back for now given that the code was >> committed without this discussion actually coming to a conclusion. >> >> Ojan >> ___ >> 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
