[webkit-dev] WEBKITOUTPUTDIR documentation

[Seo Sanghyeon]

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 Sanghyeon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Question regarding rebaseline for Layout Test Result for EFL port

[Gyuyoung Kim]

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 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.cpp, and it seems that the existing layout test result 
of EFL port was influenced by it. (http://trac.webkit.org/changeset/101343)

3,936 test cases are failed after the revision (101343).
   * EFL port's layout test result with r101343
 => Results: 16139/27915 tests passed (57.8%)
 => Tests to be fixed (11776):
   4423 text diff mismatch   (37.6%)
   9 image mismatch   ( 0.1%)
   7344 skipped  (62.4%)

   * EFL port's layout test Result without r101343
 => Results: 20074/27915 tests passed (71.9%)
 => Tests to be fixed (7841):
   1 test timed out   ( 0.0%)
   487 text diff mismatch   ( 6.2%)
   9 image mismatch   ( 0.1%)
   7344 skipped  (93.7%)

It looks GTK port also did rebaseline due to the revision.
 - http://trac.webkit.org/changeset/101354
 - http://trac.webkit.org/changeset/101352
 - http://trac.webkit.org/changeset/101351
 - And so on.

I think EFL port also needs to do rebaseline for layout test result. GTK port 
did rebaseline without review because patch is too huge. Is there any processes 
for rebaseline ?

- gyuyoung
___
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] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

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 (*). Enough said.

RFC 5987 support would be outside of open source WebKit for Safari, and is thus 
off topic for this list.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

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 compliance.


To me, this seems like your strongest argument. However…


  b) Most user agents, including most browsers, do not have this
behavior.


Is this true? In Bugzilla, I saw Alexey request cross-browser testing, but I 
didn't see any testing results, other than Alexey's testing of Firefox 9, which 
did have this behavior. So, the tested user agent compatibility score seems to 
be 2-1 (Safari and Firefox vs Chrome).

Browser compatibility seems to be Alexey's strongest argument for not following 
the HTTP working group's consensus. If there were no tradeoff between the 
working group's consensus and browser compatibility, I suspect that Alexey's 
position might change.

Can you supply more information here? Which web browsers have been tested, what 
were the tests, and what were the results?


Eric Lawrence does a good job explaining some of this history of this
topic in this blog post:

http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx

Prior to RFC 5987, there was no way for servers to represent a
non-ASCII filename in the Content-Disposition header in a way that
would be interpreted consistently by user agents.  The different
interoperability camps broke down roughly as IE+Chrome and
Firefox+Safari+Opera, although even within those camps there were
inconsistencies.  What a mess!


Almost. RFC 5987 is a tiny revision of RFC 2231, and Firefox, Opera and 
Konqueror have been implemented this for many many years. So the only 
UAs missing where IE (fixed in IE9), Chrome (fixed in Chrome ~9), and 
Safari (not fixed).



The HTTP working group took up this issue, worked through the various
trade-offs and reached consensus around RFC 5987.  There are certainly
parts of RFC 5987 I'm not super happy about (and that I argued
against, unsuccessfully), but that's the way we can make progress on
these topics: we participate in the standards process, make
compromises, and respect the outcome.


Thanks.


All that being said, if you don't wish to comply with this standard at
this time, that's your choice.  I'm just asking for an ifdef so I can
turn this non-standards compliant code off in the Chromium port.


2) Stability.  This code crashes.


This argument seems like a red herring to me. We should make a decision about 
deprecatedFrameEncoding on its merits. If deprecatedFrameEncoding is the right 
behavior for WebKit, let's fix the crashes. If deprecatedFrameEncoding is the 
wrong behavior for WebKit, let's remove it. Either way, crashes aren't the 
deciding factor.


I don't agree that the stability of the code is a non-issue, but I'm
willing to argue point (1) first.

2012/1/16 Alexey Proskuryakov:

The whole topic is quite isolated and inconsequential, so the intensity of 
argument (particularly in bug 67882 and its patch) does not appear adequate.


None of your email is a technical argument in response to my technical
argument.  If you feel that this issue is inconsequential, then it
shouldn't be a big deal to let me disable this code on the Chromium
port.


Out of curiosity: which part of the stack does this belong to? I'm a bit 
confused because Chrome does implement RFC 5987, and apparently that's 
not in the Webkit code. Maybe the simple answer is to fork the code for 
Content-Disposition, and move everything you need into Chrome?


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

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 aspects of RFC 6266. For example, Chrome uses 
default encoding instead of US-ASCII to interpret Content-Disposition bytes. 
This is clearly a case of using external context to interpret the response, and 
a violation of letter and spirit of the spec.


RFC 6266 doesn't mandate US-ASCII here. It defaults to what HTTP/1.1 
defaults to, and that is ISO-8859-1.


According to , all 
UAs do that in absence of out-of-band information, and given a valid 
ISO-8859-1 octet sequence that doesn't look like UTF-8.


Now I'm the first one to agree that ISO-8859-1 was a bad choice as 
default. It's for historical reasons. Blame those who worked on the 
specs in 90s.



There is a long history of HTTP related specs disregarding browser needs when 
it comes to non-ASCII characters in headers fields, or to stateful 
interpretation of responses.


"There's a long history of browser makers ignoring the standards process 
and writing crappy implementations".


Not productive.

If you don't like where the specs are headed, provide feedback to the 
Working Groups producing them.



This is a discussion that we had before, including on this list. I don't think 
that enough has changed to make spending time on this again very useful. The 
whole topic is quite isolated and inconsequential, so the intensity of argument 
(particularly in bug 67882 and its patch) does not appear adequate.


I support Adam in his proposal to clean up the mess. 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 (*). Enough said.


Best regards, Julian

(*) IE9 only supports UTF-8, but see 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

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 seems like your strongest argument. However…
>
>>  b) Most user agents, including most browsers, do not have this
>> behavior.
>
> Is this true? In Bugzilla, I saw Alexey request cross-browser testing, but I 
> didn't see any testing results, other than Alexey's testing of Firefox 9, 
> which did have this behavior. So, the tested user agent compatibility score 
> seems to be 2-1 (Safari and Firefox vs Chrome).
>
> Browser compatibility seems to be Alexey's strongest argument for not 
> following the HTTP working group's consensus. If there were no tradeoff 
> between the working group's consensus and browser compatibility, I suspect 
> that Alexey's position might change.
>
> Can you supply more information here? Which web browsers have been tested, 
> what were the tests, and what were the results?

Eric Lawrence does a good job explaining some of this history of this
topic in this blog post:

http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx

Prior to RFC 5987, there was no way for servers to represent a
non-ASCII filename in the Content-Disposition header in a way that
would be interpreted consistently by user agents.  The different
interoperability camps broke down roughly as IE+Chrome and
Firefox+Safari+Opera, although even within those camps there were
inconsistencies.  What a mess!

The HTTP working group took up this issue, worked through the various
trade-offs and reached consensus around RFC 5987.  There are certainly
parts of RFC 5987 I'm not super happy about (and that I argued
against, unsuccessfully), but that's the way we can make progress on
these topics: we participate in the standards process, make
compromises, and respect the outcome.

All that being said, if you don't wish to comply with this standard at
this time, that's your choice.  I'm just asking for an ifdef so I can
turn this non-standards compliant code off in the Chromium port.

>> 2) Stability.  This code crashes.
>
> This argument seems like a red herring to me. We should make a decision about 
> deprecatedFrameEncoding on its merits. If deprecatedFrameEncoding is the 
> right behavior for WebKit, let's fix the crashes. If deprecatedFrameEncoding 
> is the wrong behavior for WebKit, let's remove it. Either way, crashes aren't 
> the deciding factor.

I don't agree that the stability of the code is a non-issue, but I'm
willing to argue point (1) first.

2012/1/16 Alexey Proskuryakov :
> The whole topic is quite isolated and inconsequential, so the intensity of 
> argument (particularly in bug 67882 and its patch) does not appear adequate.

None of your email is a technical argument in response to my technical
argument.  If you feel that this issue is inconsequential, then it
shouldn't be a big deal to let me disable this code on the Chromium
port.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

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 
default encoding instead of US-ASCII to interpret Content-Disposition bytes. 
This is clearly a case of using external context to interpret the response, and 
a violation of letter and spirit of the spec.

There is a long history of HTTP related specs disregarding browser needs when 
it comes to non-ASCII characters in headers fields, or to stateful 
interpretation of responses.

This is a discussion that we had before, including on this list. I don't think 
that enough has changed to make spending time on this again very useful. The 
whole topic is quite isolated and inconsequential, so the intensity of argument 
(particularly in bug 67882 and its patch) does not appear adequate.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] ProgressEvents for Images

[Bear Travis]

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 image to a progress element
like this:



Developers have taken various tacks to enable progress reporting, for example
in some cases XHR can be used to download image files.  Max Vujovic just
published a blog about the practicalities of doing so:
http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/.  We
think it would be preferable to provide support for image progress events
directly.

We're working on a prototype implementation for WebKit and have filed a bug
that explains what we're up to in a little more detail:
https://bugs.webkit.org/show_bug.cgi?id=76102

It's probably worth pointing out that the beforeload event, which is currently
under discussion, addresses a different use case.  Our proposal is intended to
enable applications to give the user feedback about image download progress,
it's not intended to enable security or efficiency by preemptively blocking or
transforming image downloads.

We'd appreciate feedback on this proposal.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Geoffrey Garen]

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 user agents, including most browsers, do not have this
> behavior.

Is this true? In Bugzilla, I saw Alexey request cross-browser testing, but I 
didn't see any testing results, other than Alexey's testing of Firefox 9, which 
did have this behavior. So, the tested user agent compatibility score seems to 
be 2-1 (Safari and Firefox vs Chrome).

Browser compatibility seems to be Alexey's strongest argument for not following 
the HTTP working group's consensus. If there were no tradeoff between the 
working group's consensus and browser compatibility, I suspect that Alexey's 
position might change.

Can you supply more information here? Which web browsers have been tested, what 
were the tests, and what were the results?

> 2) Stability.  This code crashes.

This argument seems like a red herring to me. We should make a decision about 
deprecatedFrameEncoding on its merits. If deprecatedFrameEncoding is the right 
behavior for WebKit, let's fix the crashes. If deprecatedFrameEncoding is the 
wrong behavior for WebKit, let's remove it. Either way, crashes aren't the 
deciding factor.

Best,
Geoff
___
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

[David Hyatt]

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] HTML notification usage

[Adam Barth]

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 for text notifications.

Adam


On Mon, Jan 16, 2012 at 1:36 PM, Kenneth Rohde Christiansen
 wrote:
> 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?
>
> Kenneth
>
> On Mon, Jan 16, 2012 at 10:25 PM, Jon Lee  wrote:
>> 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
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> --
> Kenneth Rohde Christiansen
> Senior Engineer
> Nokia Mobile Phones, Browser / WebKit team
> Phone  +45 4093 0598 / E-mail kenneth at webkit.org
>
> http://codeposts.blogspot.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] HTML notification usage

[Kenneth Rohde Christiansen]

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?

Kenneth

On Mon, Jan 16, 2012 at 10:25 PM, Jon Lee  wrote:
> 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
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] HTML notification usage

[Jon Lee]

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Jochen Eisinger]

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 about whether the requesting context should be a factor in
> determining the character set used to decode the Content-Disposition
> header.  The working group decided that we shouldn't use that
> information for several reasons:
>
>  a) Varying the interpretation of an HTTP response based on the
> context of the request is contrary to the stateless nature of HTTP.
> The fact that HTTP request/response pairs can be understood
> irrespective of context is core to the design of HTTP.
>
>  b) Most user agents, including most browsers, do not have this
> behavior.  That means the compatibility risk for dropping the behavior
> in other user agents (e.g., Safari) is relatively low, especially for
> a feature likes this one that is not widely used on the mobile web.
>
> 2) Stability.  This code crashes.  For example, in the most recent
> release of Chrome Canary on Windows, deprecatedFrameEncoding accounts
> for 3.5% of all renderer crashes.  While we could invest effort in
> fixing these crashes, we'd be better off removing this code and
> spending that effort improving stability elsewhere.
>

For the sake of completeness: The crashes I've seen end in

[DocumentWriter.cpp:246] WebCore::DocumentWriter::deprecatedFrameEncoding()
[FrameLoader.cpp:2591] WebCore::FrameLoader::addExtraFieldsToRequest()
[FrameLoader.cpp:1191] WebCore::FrameLoader::loadURL()

implying that the FrameLoader doesn't have an active document loader at
that point.

-jochen



> If removing deprecatedFrameEncoding isn't possible at this time, we
> should revert http://trac.webkit.org/changeset/104723 because it
> causes crashes.  Rather than get into a revert war, however, I believe
> the project would be better served by talking out this issue.
>
> 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] New CSS property -webkit-control-text-overflow

[Jon Lee]

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

[David Hyatt]

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] Implementing Shadow DOM spec in WebKit

[Vincent Hardy]

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 let you know that we are planning to implement the Shadow
DOM specification
(http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html)
in WebKit. For now, its public-facing APIs will hide behind
ENABLE(SHADOW_DOM) flag and help gather implementer and developer
feedback.

Shadow DOM spec is part of the Web Components effort (see overview
here: 
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html),
and is on the standards track in the WebApps WG. Work is ongoing
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14972), with
participation from Microsoft and Mozilla. Adobe also expressed
interest in contributing.

In addition, Shadow DOM is being considered as the replacement of
similar plumbing in SVG for SVG v.Next. This particular effort is just
starting in SVG WG.

The meta bug to follow is https://bugs.webkit.org/show_bug.cgi?id=63606.

:DG<

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Question regarding rebaseline for Layout Test Result for EFL port

[Antonio Gomes]

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.cpp, and it seems that the existing layout test
> result of EFL port was influenced by it. (
> http://trac.webkit.org/changeset/101343)
>
> 3,936 test cases are failed after the revision (101343).
>* EFL port's layout test result with r101343
>  => Results: 16139/27915 tests passed (57.8%)
>  => Tests to be fixed (11776):
>4423 text diff mismatch   (37.6%)
>9 image mismatch   ( 0.1%)
>7344 skipped  (62.4%)
>
>* EFL port's layout test Result without r101343
>  => Results: 20074/27915 tests passed (71.9%)
>  => Tests to be fixed (7841):
>1 test timed out   ( 0.0%)
>487 text diff mismatch   ( 6.2%)
>9 image mismatch   ( 0.1%)
>7344 skipped  (93.7%)
>
> It looks GTK port also did rebaseline due to the revision.
>  - http://trac.webkit.org/changeset/101354
>  - http://trac.webkit.org/changeset/101352
>  - http://trac.webkit.org/changeset/101351
>  - And so on.
>
> I think EFL port also needs to do rebaseline for layout test result. GTK
> port did rebaseline without review because patch is too huge. Is there any
> processes for rebaseline ?
>
> - gyuyoung
> ___
> 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

[webkit-dev] Question regarding rebaseline for Layout Test Result for EFL port

[Gyuyoung Kim]

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/changeset/101343)

3,936 test cases are failed after the revision (101343). 
* EFL port's layout test result with r101343
  => Results: 16139/27915 tests passed (57.8%)
  => Tests to be fixed (11776):
4423 text diff mismatch   (37.6%)
9 image mismatch   ( 0.1%)
7344 skipped  (62.4%)

* EFL port's layout test Result without r101343
  => Results: 20074/27915 tests passed (71.9%)
  => Tests to be fixed (7841):
1 test timed out   ( 0.0%)
487 text diff mismatch   ( 6.2%)
9 image mismatch   ( 0.1%)
7344 skipped  (93.7%)

It looks GTK port also did rebaseline due to the revision.
 - http://trac.webkit.org/changeset/101354
 - http://trac.webkit.org/changeset/101352
 - http://trac.webkit.org/changeset/101351
 - And so on.

I think EFL port also needs to do rebaseline for layout test result. GTK port 
did rebaseline without review because patch is too huge. Is there any processes 
for rebaseline ?

- gyuyoung
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev