[webkit-dev] Progress
-Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
I know that Adam Barth was the driving force behind this, since it was his turn at gardening WebKit (that's a Chromium thing http://www.chromium.org/developers/how-tos/webkit-merge-1). I wonder if we as a community would benefit from a cross-organizational rotation like this? Remembering strong negative reaction to this idea last time -- (more process is bad!) -- but hey, all-green tree is freaking amazing. :DG On Fri, Apr 1, 2011 at 6:30 AM, Adam Roben aro...@apple.com wrote: -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev Screen Shot 2011-04-01 at 9.29.19 AM.png___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
On Apr 1, 2011, at 10:03 AM, Dimitri Glazkov wrote: I know that Adam Barth was the driving force behind this, since it was his turn at gardening WebKit (that's a Chromium thing http://www.chromium.org/developers/how-tos/webkit-merge-1). I wonder if we as a community would benefit from a cross-organizational rotation like this? Jessie Berlin and I have been trying to pitch in as well over the course of the week. (We have a rotation similar to Chromium's gardeners inside Apple, but it's fairly new.) I think it is definitely helpful to have more eyes on the bots. Hopefully we can come up with some ideas for how to make gardeners less important by making the bots keep themselves green. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
Major kudos to Adam (Barth) for all his gardening efforts this week! (Somehow this slipped out of my previous message.) -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
I am so glad you guys are test-driving gardening too. Yay team! :) :DG On Fri, Apr 1, 2011 at 7:09 AM, Adam Roben aro...@apple.com wrote: Major kudos to Adam (Barth) for all his gardening efforts this week! (Somehow this slipped out of my previous message.) -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
On Fri, Apr 1, 2011 at 7:06 AM, Adam Roben aro...@apple.com wrote: Jessie Berlin and I have been trying to pitch in as well over the course of the week. (We have a rotation similar to Chromium's gardeners inside Apple, but it's fairly new.) I think it is definitely helpful to have more eyes on the bots. Igalia has a rotation of people keeping the tree green as well. Here's the current list if you're curious who you should poke about GTK+ redness: Monday: Alejandro Garcia Castro (alexg) Tuesday: Mario Sanchez Prada (msanchez) Wednesday: Martin Robinson (mrobinson) Thursday: Philippe Normand (pnormand or philn) Friday: Sergio Villar Senin (svillar) --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
I must say Qt has (the tireless) Ossy and Szeged crew almost 24hours/day :o, as you had probably noticed/ On Fri, Apr 1, 2011 at 12:11 PM, Martin Robinson mrobin...@webkit.orgwrote: On Fri, Apr 1, 2011 at 7:06 AM, Adam Roben aro...@apple.com wrote: Jessie Berlin and I have been trying to pitch in as well over the course of the week. (We have a rotation similar to Chromium's gardeners inside Apple, but it's fairly new.) I think it is definitely helpful to have more eyes on the bots. Igalia has a rotation of people keeping the tree green as well. Here's the current list if you're curious who you should poke about GTK+ redness: Monday: Alejandro Garcia Castro (alexg) Tuesday: Mario Sanchez Prada (msanchez) Wednesday: Martin Robinson (mrobinson) Thursday: Philippe Normand (pnormand or philn) Friday: Sergio Villar Senin (svillar) --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
Hi, On Sat, Mar 5, 2011 at 11:24 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Mar 4, 2011 at 12:16 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Mar 2011, Dimitri Glazkov wrote: Today, we happily use -webkit-appearance to apply platform-specific appearance to the controls. The trouble is, the value of -webkit-appearance is going to be different depending on the value of logical width. Why not have a value of 'appearance' that automatically uses the right orientation, instead of having orientation-specific values? You are correct, the theme can paint correctly oriented slider controls in by looking at the box size it's painting. Hyatt pointed out the same thing on #webkit. However, the issue still exists in the cases of meter and progress. They are using plain-old CSS gradient rules, not magic platform painter (calked RenderTheme in WebKit). It's true. I'll add a context here. For Mac, which has native meter (indicator) components, WebKit uses platform painter. But for platforms other than mac, WebKit use two gradient-filled divs (one for the bar and another for background) to render the meter, because such platforms don't have own native indicators. Another idea to select the direction explicitly is to refer writing-mode or box-orient CSS property. I'm not sure whether this is a good idea though. Regards. -- morrita :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
Dear WebKit,
It seems we have a bit of a conundrum with spec-conforming element
rendering. The
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-meter-element-0,
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0,
and
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-input-element-as-a-range-control
all state something along these lines:
When the control is wider than it is tall (or square), the control is
expected to be a horizontal slider, with the lowest value on the right
if the 'direction' property on this element has a computed value of
'rtl', and on the left otherwise. When the control is taller than it
is wide, it is expected to be a vertical slider, with the lowest value
on the bottom.
How shall we accomplish this?
Today, we happily use -webkit-appearance to apply platform-specific
appearance to the controls. The trouble is, the value of
-webkit-appearance is going to be different depending on the value of
logical width.
For example, consider input type=range style=width: 100%; height: 200px
http://jsfiddle.net/dglazkov/qmnKN/1/embedded/result/
If the logical width of the control is over 200px, the property
-webkit-appearance: sliderthumb-horizontal applies to it.
As you size the window down, at the point where the width of the
control is less than 200px, the property -webkit-appearance:
sliderthumb-vertical should start apply to it.
One could imagine something like this for a set of rules to describe this:
input[type=range]:horizontal::-webkit-slider-thumb {
-webkit-appearance: sliderthumb-horizontal;
}
input[type=range]:vertical::-webkit-slider-thumb {
-webkit-appearance: sliderthumb-vertical;
}
where horizontal and vertical pseudo-classes are applied according
to logical width/height ration of the control box. This seems gross,
since we'll need to create a new rendering primitive
(RenderGrossOrientationAwareBox?), which re-matches style during
layout, as early as the logical width of a box can be determined.
Tab pointed out to me that introducing something like this would also
be a bad idea, since the logical width/height ration may be affected
by the newly-re-matched rules:
foo:vertical {
width: 1px; /* no longer vertical */
}
So it sucks. Please help with better ideas?
Our options:
a) add a gross hack in layout for these elements to re-match style
after calculating logical width
b) do something even grosser.
c) do something more brilliant.
d) not implement this part of the spec.
P.S. This is a continuation of discussion on
https://bugs.webkit.org/show_bug.cgi?id=54440.
:DG
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
On Fri, 4 Mar 2011, Dimitri Glazkov wrote: Today, we happily use -webkit-appearance to apply platform-specific appearance to the controls. The trouble is, the value of -webkit-appearance is going to be different depending on the value of logical width. Why not have a value of 'appearance' that automatically uses the right orientation, instead of having orientation-specific values? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
On Fri, Mar 4, 2011 at 12:16 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Mar 2011, Dimitri Glazkov wrote: Today, we happily use -webkit-appearance to apply platform-specific appearance to the controls. The trouble is, the value of -webkit-appearance is going to be different depending on the value of logical width. Why not have a value of 'appearance' that automatically uses the right orientation, instead of having orientation-specific values? You are correct, the theme can paint correctly oriented slider controls in by looking at the box size it's painting. Hyatt pointed out the same thing on #webkit. However, the issue still exists in the cases of meter and progress. They are using plain-old CSS gradient rules, not magic platform painter (calked RenderTheme in WebKit). :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Progress Indicator rules
Good day, everyone, As a web developer, I've tried to find an explanation of when Webkit/Safari decides that the page is done loading, but come up empty-handed. I want to issue a long-lived XHR relatively soon after page load to receive events from a server. Unfortunately, if I do this even a second or so after onload fires, the XHR will cause the load progress indicator to stay on permanently. I have to wait several seconds - 3-5 or so before issuing the request for it not to be considered (apparently) part of the initial page load. Can anyone explain, or has someone already, the sequence of events while loading the page, in terms of DOM events and the progress (busy) indicator? How can I know from javascript that the page load is complete, since this is apparently not the case before onload fires? Many thanks, Peter Abrahamsen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
