Re: [webkit-dev] What to do about scroll anchoring?

2019-09-29 Thread L. David Baron
On Friday 2019-09-27 14:23 +0200, Emilio Cobos Álvarez wrote:
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?

It seems pretty sad, since I think it's a very useful feature for a
large class of pages -- particularly pages that are more "documents"
than "applications".

I wonder if it would be possible to disable the feature under
certain conditions, for example:
 * the page uses APIs that initiate scrolling from script, or
 * the page has handlers for scroll events, or
 * the page does both of the above
but leave the feature enabled for pages that don't do these things.

Based on what I've heard it seems like many of the cases where pages
are really broken involve some of those, although I haven't gone
through the bug lists.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] What to do about scroll anchoring?

2019-09-29 Thread L. David Baron
On Sunday 2019-09-29 10:54 +1000, Cameron McCormack wrote:
> How useful is scroll anchoring outside of the two cases mentioned in 
> https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and 
> ad iframes being inserted?  Would it be feasible to make scroll anchoring a 
> much less general mechanism, and to scope it down to handling these specific 
> cases?

I think it's also quite useful for horizontal resizes of the browser
window (which can include device rotation on mobile, window
resizing/maximization on desktop, and also hiding/showing of browser
sidebar UI).

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

2015-11-06 Thread L. David Baron
On Friday 2015-11-06 07:16 -0800, Darin Adler wrote:
> > On Nov 5, 2015, at 11:24 PM, L. David Baron <dba...@dbaron.org> wrote:
> > 
> > For what it's worth, Gecko does have code to produce a
> > minimal-length alpha value.  nsStyleUtil::ColorComponentToFloat just
> > tries rounding to 2 decimal places, sees if the resulting float
> > round-trips back to the same 0-255 alpha value, and if it doesn't,
> > rounds to 3 places.
> 
> Got it. Sounds like it does what I have in mind. Except that given what you 
> say it sounds like it doesn’t use a single decimal place even if that round 
> trips, so for 51 it uses 0.20 rather than 0.2.

The float -> string code handles that, though, so it does come out
as 0.2.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

2015-11-05 Thread L. David Baron
On Monday 2015-11-02 08:37 -0800, Simon Fraser wrote:
> > On Nov 1, 2015, at 7:40 PM, Darin Adler <da...@apple.com> wrote:
> > 
> > Hi folks.
> > 
> > Our engine supports alpha values from 0-255. But when we serialize them, we 
> > turn them into floating point values. When we do that, we include way too 
> > many digits of precision. For example, the alpha value 127 becomes 0.498039.
> > 
> > I like the idea of writing the minimum number of digits that are needed to 
> > round trip. So 127 would become 0.498 or even maybe 0.49 and 128 would 
> > become 0.5.
> > 
> > Three questions:
> > 
> > 1) Does the CSS specification allow or encourage this?
> 
> As long as the values round-trip, I think it’s OK.
> 
> > 2) Do you like this idea?
> 
> I would like to know what other browsers do.

For what it's worth, Gecko does have code to produce a
minimal-length alpha value.  nsStyleUtil::ColorComponentToFloat just
tries rounding to 2 decimal places, sees if the resulting float
round-trips back to the same 0-255 alpha value, and if it doesn't,
rounds to 3 places.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Test frame size for reftests

2013-04-24 Thread L. David Baron
On Wednesday 2013-04-24 09:55 -0700, Darin Adler wrote:
 On Apr 23, 2013, at 11:36 AM, Benjamin Poulain benja...@webkit.org wrote:
 
  The current mode works fine for some ref-tests but is really annoying for 
  others. I would love to have a way to compare the entire page instead of 
  the viewport.
  
  Maybe it could just be an API on testrunner? Like:
  testRunner.dumpEntirePagePixels()?
 
 What’s the downside of just doing this for all reftests? Would it
 make them slower? Would it cause failures? I’d love it if we could
 just do it without it having to be opt-in.

Tests that rely on this wouldn't be sharable with other browsers or
usable in W3C test suites, at least based on current practice.

(I think we had some sort of agreement within some set of people
involved with W3C reftests to use 800x600.  Mozilla is currently
using 800x1000, though I'd like to switch to the smaller size.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla   http://www.mozilla.org/   턂
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal to remove list-item special counter

2013-01-17 Thread L. David Baron
On Wednesday 2013-01-16 18:25 -0800, Darin Adler wrote:
 On Jan 16, 2013, at 5:46 PM, Elliott Sprehn espr...@chromium.org wrote:
 
  I've scoured the web and can't find any reference to anyone using it, 
  mention of it's usage on any pages and no other browser supports it.
 
 How much more common is use of the rest of the counters specification? I 
 understand that counters is still a leading-edge feature that isn’t likely to 
 be used much on the real web yet.
 
 The list-item counter is used in the very first example in the CSS Lists and 
 Counters Module http://www.w3.org/TR/css3-lists/. I don’t understand why 
 you are so eager to throw it under the bus.
 
  In terms of harm, it adds implementation complexity, especially when I want 
  to rewrite counters to be much simpler and faster.
  
  I'd like to go ahead with the removal and then we can bring this back if 
  developers show interest. Does that sound reasonable?
 
 If you really want to remove it, and all the other browser vendors agree, 
 maybe you can get it removed from the CSS working draft.

For what it's worth, reimplementing Gecko's list numbering using
counters is something I'd like to do; it's just not so high on the
priority list these days.  (Our current list numbering code has a
bunch of weird bugs that our counter implementation does not have.
That said, I think implementing list numbering using counters might
require implementing the new 'counter-set' in addition to the
existing 'counter-increment' and 'counter-reset'.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla   http://www.mozilla.org/   턂
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev