https://bugs.webkit.org/attachment.cgi?id=270221=review
> On Jan 21, 2016, at 8:35 AM, Morten Stenshorne <msten...@opera.com> wrote:
>
> Thanks for your quick response!
>
> David Hyatt <hy...@apple.com> writes:
>
>> We are in favor of those properti
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
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
On Apr 17, 2013, at 2:26 AM, Yuki Sekiguchi yuki.sekigu...@access-company.com
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
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 aba...@webkit.org wrote:
I noticed this comment on the Hacker News thread about Paul Irish's
recent blog post:
---8---
CSS parsing is the
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
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
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
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
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
On Aug 20, 2012, at 12:40 PM, Alan Stearns wrote:
On 8/20/12 10:07 AM, David Hyatt hy...@apple.com 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
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
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
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
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 milian.wo...@kdab.com:
Ping? Could someone be so kind as to answer my questions
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
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
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
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
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
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
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
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
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
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.
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
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.,
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
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
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
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 hy...@apple.com wrote:
As was mentioned already, we've been trying to follow the general guideline
of dropping
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-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
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
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
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
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
On Dec 3, 2010, at 3:33 PM, Darin Fisher wrote:
On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel e...@webkit.org 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.
)
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
WebKit enforces a minimum font size of 9px when no explicit font size is
specified. This means that the font for rt 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.
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
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
PM, David Hyatt hy...@apple.com 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
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
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
(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
On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:
On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com 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
19, 2010 at 11:29 AM, David Hyatt hy...@apple.com 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
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 da...@apple.com 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
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
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:
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
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;
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,
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
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
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
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote:
2010/9/1 Alexey Proskuryakov a...@webkit.org:
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
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
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
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
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
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
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
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
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
On Sat, Aug 14, 2010 at 4:21 PM, k...@inf.u-szeged.hu 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
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:
PassRefPtrImage copyImage()
This function should always simply copy the image. It is used in any place
where you want to get a snapshot of the
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
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
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
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
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
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
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
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
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
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
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
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 Thu, Jun 10, 2010 at 12:26 PM, David Hyatt hy...@apple.com 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
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
In fact the (really lousy) model I've employed in the past when this situation
has arisen is that I hack the render tree dump to continue to dump the old
rendering. The render tree dumping code is full of hacks as a result and is
basically lying about many things at this point.
It would be
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 sam.wei...@gmail.com wrote:
After talking it over with some folks here at Apple, I want to formally
be a better answer in both situations.
-- Dirk
On Fri, Jun 4, 2010 at 10:36 AM, David Hyatt hy...@apple.com wrote:
In fact the (really lousy) model I've employed in the past when this
situation has arisen is that I hack the render tree dump to continue to dump
the old rendering. The render
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
Really? I thought they did, at least for stylesheets.
dave
On Jun 3, 2010, at 8:14 AM, Gavin Peters (蓋文彼德斯) wrote:
No, no other browsers support it. There's a similar feature in Mozilla, the
LINK rel=prefetch item, but to my knowledge, Mozilla does not support the
Link header.
On Wed,
On Jun 2, 2010, at 5:28 PM, Gavin Peters (蓋文彼德斯) wrote:
I don't think I'll share much code .
Try to share as much code as you can, assuming it makes sense to do so. We
could always refactor common code into something like a CSSStyleSheetLoader
class if we needed to.
dave
On Jun 2, 2010, at 2:46 PM, Antonio Gomes (:tonikitoo) wrote:
Hi,
As most of you have experienced, the precision of a mouse click on
Desktop applications, including Web browsers, is much higher than the
precision of a touch tap on a mobile device. It is not a new problem,
and many
He would want 1,1.
dave
On Jun 2, 2010, at 3:58 PM, Peter Kasting wrote:
On Wed, Jun 2, 2010 at 1:52 PM, Antonio Gomes (:tonikitoo)
toniki...@gmail.com wrote:
If a port do not want to
take advantage of the new support, the current functionality should
and would be kept, i.e.
I think we should support rgba/hsla colors in SVG.
dave
On Jun 1, 2010, at 12:23 PM, Dirk Schulze wrote:
The SVG 1.1 specification has a reference to CSS2. So from the
specifications point of view, rgba() shouldn't be supported.
Nevertheless SVG 1.1se won't have a strict reference to CSS2.
In general our strategy for table rendering is to match whatever Internet
Explorer does.
Try your table test cases in IE for Windows in both quirks mode (no doctype)
and strict mode (!doctype html) and see what IE does. Assuming IE's
rendering makes sense, that's probably what we want to do
,
Fady
On Tue, May 18, 2010 at 2:57 PM, David Hyatt hy...@apple.com wrote:
On May 18, 2010, at 12:52 PM, Fady Samuel wrote:
Hi all,
I'm looking at table hit testing, and in all the simple test cases I've
tried, it seems to show that RenderTable never has the flag
On May 20, 2010, at 3:07 PM, David Hyatt wrote:
If we could properly detect those degenerate cases, then you could probably
get away with binary search, but until we do that, I don't think you can.
Here's an example:
STYLE
TD:hover { color: green }
/STYLE
TABLE border=1
TRTD1 TD2 TD3
TRTD4
On May 20, 2010, at 3:52 PM, Fady Samuel wrote:
I'm still confused about the proper ordering of painting/hit testing cells
for a given grid position.
In the example you provided, David, WHY does cell 7 have precedence over cell
5? Is it based on the order they're defined?
Yes, it's
On May 20, 2010, at 3:38 PM, Fady Samuel wrote:
So what are the rules for stacking here? do the cells stack in the order in
which they appear in the HTML?
Correct, although note that backgrounds paint behind foregrounds, and hit
testing works the same way, so it's not as simple as saying
On May 18, 2010, at 12:52 PM, Fady Samuel wrote:
Hi all,
I'm looking at table hit testing, and in all the simple test cases I've
tried, it seems to show that RenderTable never has the flag m_hasOverflowClip
set to true. What this means is that all the table's children are ALWAYS
checked
There are also a fair number of directories that test rendering and layout,
although they are usually obvious by their names... many of the subdirectories
in fast cannot be converted to pure text tests (clipping, margin collapsing,
backgrounds, etc.).
dave
On Apr 13, 2010, at 1:54 PM, Ojan
Images can either be bitmap images (GIF/JPG/PNG, etc.) or generated images that
care about a size (gradient, SVG). So the answer really depends on your
purpose. If you are just worried about bitmap images, then the passed in size
doesn't really matter. Otherwise the correct size to use would
On Mar 9, 2010, at 1:45 PM, Adam Barth wrote:
(1) The patch needs to be reviewed by David Hyatt. David Hyatt
appears to be a bottleneck in the project because he's an expert on a
number of components that no one else understands as well but he
doesn't spend as much time reviewing
Columns need to be completely re-written.
dave
On Feb 12, 2010, at 3:01 PM, Joseph Zuromski wrote:
I was wondering if there was any plan in the near future to support css
column-break-before, -after, and -inside in the near future? I noticed
https://bugs.webkit.org/show_bug.cgi?id=15552
1 - 100 of 210 matches
Mail list logo
