Building WebKit document at http://www.webkit.org/building/build.html
seems to suggest that WEBKITOUTPUTDIR only works on Windows,
but this is not the case.
Current wording doesn't tell how to customize build location on non-Mac
and non-Windows platforms.
Can someone reword this?
--
Seo Sanghye
Hello Antonio,
Ok, I'm going to update the test results for EFL port as GTK port's way.
- gyuyoung.
--- Original Message ---
Sender : Antonio Gomes
Date : 2012-01-17 02:54 (GMT+09:00)
Title : Re: [webkit-dev] Question regarding rebaseline for Layout Test Result
for EFL port
I would say
16.01.2012, в 16:24, Julian Reschke написал(а):
> But we should keep in mind that what's much more important here is to
> actually provide developers with a protocol/format that is interoperable for
> non-ASCII. I note that Safari is the only current browser which doesn't
> implement RFC 5987
On 2012-01-17 01:06, Adam Barth wrote:
On Mon, Jan 16, 2012 at 3:15 PM, Geoffrey Garen wrote:
I just read through the Bugzilla bugs on this topic. Hopefully, I'm a mostly
neutral observer.
We should remove deprecatedFrameEncoding. Removing the code has the
following benefits:
1) Standards
On 2012-01-17 00:57, Alexey Proskuryakov wrote:
16.01.2012, в 15:15, Geoffrey Garen написал(а):
1) Standards compliance.
To me, this seems like your strongest argument. However…
I'm pretty sure that no major browser implements - or maybe even intends to
implement - all encoding-related as
On Mon, Jan 16, 2012 at 3:15 PM, Geoffrey Garen wrote:
> I just read through the Bugzilla bugs on this topic. Hopefully, I'm a mostly
> neutral observer.
>
>> We should remove deprecatedFrameEncoding. Removing the code has the
>> following benefits:
>>
>> 1) Standards compliance.
>
> To me, this
16.01.2012, в 15:15, Geoffrey Garen написал(а):
>> 1) Standards compliance.
>
> To me, this seems like your strongest argument. However…
I'm pretty sure that no major browser implements - or maybe even intends to
implement - all encoding-related aspects of RFC 6266. For example, Chrome uses
d
Hello Webkit,
A group of us at Adobe has been looking into adding support for ProgressEvents
to images. The overall goal is to simplify image download progress reporting
by supporting roughly the same progress events as XHR and the File API for
image elements. For example one could connect an i
Hi Adam.
I just read through the Bugzilla bugs on this topic. Hopefully, I'm a mostly
neutral observer.
> We should remove deprecatedFrameEncoding. Removing the code has the
> following benefits:
>
> 1) Standards compliance.
To me, this seems like your strongest argument. However…
> b) Most
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
I haven't followed all the details, but I believe there are two kinds
of notifications: text notifications and HTML notifications.
Historically, HTML notifications have been more controversial than
text notifications. Jon's patch removes support for HTML
notifications but appears to leave support
Could anyone brief explain the relation to
http://www.html5rocks.com/en/tutorials/notifications/quick/
and
http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html
?
I haven't followed the work with regard to notifications, so is that
work dead or are we removing legacy code?
Hello all,
I've removed support for HTML notifications on the Mac via
http://trac.webkit.org/changeset/105086. Does anyone find much usage for this
kind of notification on their respective platforms? Would it be appropriate to
remove support for this altogether?
Jon
___
On Sun, Jan 15, 2012 at 9:52 PM, Adam Barth wrote:
> We've previously discussed this topic in Bug 67882 and Bug 75905.
>
> We should remove deprecatedFrameEncoding. Removing the code has the
> following benefits:
>
> 1) Standards compliance. There was a discussion in the HTTP working
> group ab
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 a
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 beha
Hi Dmitry,
As you mention in your email, Adobe is interested in the Shadow DOM effort
and we will coordinate with you to understand better how/if/where we can
contribute.
Good luck with both the implementation and the standards work!
Kind regards,
Vincent.
Dmitry wrote:
Hi WebKit!
I wanted to
I would say GTK's way is pretty acceptable in this case.
On Mon, Jan 16, 2012 at 3:21 AM, Gyuyoung Kim wrote:
> Hello WebKit folks.
>
> It looks that the result of layout test for EFL port needs rebaseline
> because of 101343. The revision modified line spacing of font in
> SimpleFontDataFreeType
Hello WebKit folks.
It looks that the result of layout test for EFL port needs rebaseline because
of 101343. The revision modified line spacing of font in
SimpleFontDataFreeType.cpp, and it seems that the existing layout test result
of EFL port was influenced by it. (http://trac.webkit.org/chan
19 matches
Mail list logo
