Re: [webkit-dev] Removal of trailing whitespace

[Anthony Ricaud via webkit-dev]

(not a stakeholder either)

On top of ignoring whitespace, Git and Github support ignoring commits when 
performing `git blame`.

With that tool, one commit could remove trailing whitespace over the all 
project and add some editorconfig or CI checks to prevent them from coming 
back. Then, a second commit would add the first commit to the ignore-revs-file.

https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt

https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

> On 13 Apr 2023, at 08:43, Mathias Bynens via webkit-dev 
>  wrote:
> 
> (not a stakeholder; just curious)
> 
> Does it help that Git supports the `-w` / `--ignore-all-space` flag to ignore 
> whitespace changes? It works with `git diff`, `git blame`, etc.
> 
> GitHub also supports it — compare e.g.
> 
> https://github.com/WebKit/WebKit/commit/2ca55a3e19df60127dec09f3af22e4d3ab2943ec
> vs.
> https://github.com/WebKit/WebKit/commit/2ca55a3e19df60127dec09f3af22e4d3ab2943ec?w=1
> 
> On Wed, Apr 12, 2023 at 9:35 PM Chris Dumez via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> 
>>> On Apr 12, 2023, at 10:23 AM, Ryosuke Niwa via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> Yeah, enforcing that new or otherwise modified lines don’t have trailing 
>>> whitespaces would be good.
>> 
>> Yes, I wouldn’t mind that either.
>> 
>> However, https://commits.webkit.org/262879@main has just landed and if you 
>> look at the changes to Document.cpp, it is mostly spacing changes :(
>> It makes it harder to review or to identify meaningful changes in a patch 
>> after landing. It also pollutes git blame for no great reason.
>> 
>>> 
>>> - R. Niwa
>>> 
 On Apr 12, 2023, at 10:20 AM, Yusuke Suzuki >>> > wrote:
 
 I agree that we should not do it because it pollutes change history of 
 files, git-blame results, and review-diff in PR.
 But at the same time, I think there is no reason to add a new trailing 
 whitespace via a new commit.
 It is nice if we can enforce this rule only for newly added code (via 
 style-checker) not to add new trailing spaces.
 
 -Yusuke
 
> On Apr 12, 2023, at 10:08 AM, Ryosuke Niwa via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
> 
> WebKi proejctt’s long term policy has been to not do this:
> https://lists.webkit.org/pipermail/webkit-dev/2009-August/009665.html
> 
> I don’t think we should change that.
> 
> - R. Niwa
> 
>> On Apr 12, 2023, at 9:17 AM, Chris Dumez via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> I am against this because it adds a lot of noise to patches I am trying 
>> to review.
>> I have seen PRs where white space changes account for more than half the 
>> patch I am trying to review.
>> 
>> Dropping trailing spaces on the lines you’re modifying is OK but in the 
>> whole file is too noisy IMO.
>> 
>> Chris.
>> 
>>> On Apr 12, 2023, at 1:22 AM, Anne van Kesteren via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> 
>>> wrote:
>>> 
>>> To reduce the overhead of switching between projects with different
>>> whitespace requirements, I would like to suggest we start being
>>> lenient when trailing whitespace is removed. In particular when a file
>>> is being changed to fix a bug.
>>> 
>>> I could see going even further and enforcing this via the style
>>> checker, if there is appetite for that.
>>> 
>>> Thanks for considering!
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev
 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list

Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

[Anthony Ricaud]

It would be nice for contributors if those rules were enforced by a linter, 
like ESLint.

> On 10 Jul 2016, at 00:22, Sam Weinig  wrote:
> 
> 
> 
> It should probably get a parallel page to 
> https://webkit.org/code-style-guidelines/ and be updated with the same type 
> of right / wrong examples.  
> 
> Our of curiosity, other than for features that simply aren’t available in C++ 
> / Objective-C (or vice-versa), are there places where the inspector JS 
> guideline deviates from what we do in the rest of WebKit?  
> 
> - Sam
> 
>> On Jul 7, 2016, at 11:29 AM, Geoffrey Garen  wrote:
>> 
>> 
>> 
>> To make this policy easy for new folks, I agree with Ryosuke that we should 
>> extract a JS and CSS style guide that is separate from Inspector-specific 
>> concerns.
>> 
>> Geoff
>> 
>>> On Jul 6, 2016, at 10:17 PM, Filip Pizlo  wrote:
>>> 
>>> I like the idea of adopting inspector style for JS builtins!
>>> 
>>> It might also be good to adopt it for JS tests that we write ourselves, 
>>> with an escape hatch if you need to violate style to test some feature. For 
>>> example, it should be a goal to follow inspector style for the JetStream 
>>> harness code, and probably for all of ES6SampleBench. New JS tests in 
>>> JavaScriptCore/tests/stress that we write ourselves probably should follow 
>>> inspector style, because it's code that we have to read and understand and 
>>> I can't think of a reason not to be consistent. Thoughts?
>>> 
>>> -Filip
>>> 
 On Jul 6, 2016, at 7:53 PM, Ryosuke Niwa  wrote:
 
> On Wed, Jul 6, 2016 at 7:34 PM, Dean Jackson  wrote:
> I propose we make it official that the Web Inspector Coding Style is what 
> must be used for all JavaScript and CSS that count as source code in the 
> project.
> https://trac.webkit.org/wiki/WebInspectorCodingStyleGuide
> 
> Now that JavaScript is used in more places (JS builtins, some parts of 
> the DOM, media controls) it would be nice to make it all consistent. Note 
> that the page above can't decide if it is just JS or both JS and CSS, but 
> I think it should be both.
 
 It's hard to tell which parts of the above guide would apply to
 non-Inspector JS code because it has a bunch of Inspector specific
 guidelines such as layering guides and references to
 https://trac.webkit.org/browser/trunk/Source/WebInspectorUI/UserInterface/Views/Variables.css
 
 We should probably extract the parts that matter into a separate MD
 file or a section in the wiki page before we proceed with this
 discussion.
 
 - R. Niwa
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Mozilla -moz-any() selectors extension

[Anthony Ricaud]

I think it's a good addition.

Another nice grouping feature would be something like a @subtree() or @scope() 
rule. 

@subtree(#menu ul) {
li {}
li:hover {}
a {}
}

would expand as

#menu ul li {}
#menu ul li:hover {}
#menu ul a {}

It's a common feature from CSS compilers such as LESS 
(http://lesscss.org/docs) or CleverCSS (http://sandbox.pocoo.org/clevercss/). 
And it's very useful to style areas of a page.

Le 25 avr. 2010 à 02:14, Maciej Stachowiak a écrit :

 
 Do we want a -webkit version of this?
 
 http://dbaron.org/log/20100424-any
 
 - Maciej
 
 ___
 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] Making browsers faster: Resource Packages

[Anthony RICAUD]

I don't see much value in this proposition.

For CSS and JS, people will need to run a script to generate the ZIP
file. That's what they already do when combining files. And they get
more value by combining since they get performance improvements for
all browsers, not just the one supporting resource-packages.

For CSS Sprites, the W3C is working on making it better with
http://www.w3.org/TR/css3-images/. Maybe you should put some efforts
on this spec. And again, with the actual situation, the code is maybe
ugly but you get performance benefits for all browsers.

The only benefit would eventually be for inline images. But you can't
generate a static ZIP file for such moving content so I don't see a
lot of persons taking advantage of this proposition for that kind of
content. Thinking out loud, maybe something like img src=file.png
from=file.zip would be more appropriate for that particular kind of
content. This way, browsers now upfront if a file can be found in a
package.

I sure like the idea of trying to reduce the number of HTTP requests,
but I don't think it's the right solution.

On Tue, Nov 17, 2009 at 11:19 PM, Alexander Limi l...@mozilla.com wrote:
 Good people of Webkit!

 We'd all like for the web to be faster, and therefore I'd love your feedback
 on my proposal — it would be great to see support for this in additional
 browsers, not just Firefox:

 http://limi.net/articles/resource-packages/

 Summary:
 What if there was a backwards compatible way to transfer all of the
 resources that are used on every single page in your site — CSS, JS, images,
 anything else — in a single HTTP request at the start of the first visit to
 the page? This is what Resource Package support in browsers will let you do.

 Looking forward to hear your thoughts on this.

 Thanks!

 --
 Alexander Limi · Firefox User Experience · http://limi.net


 ___
 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] Implementation thoughts on HTML5 elements

[Anthony Ricaud]

Le 26 août 09 à 12:29, Michelangelo De Simone a écrit :


2009/8/26 Anthony Ricaud rik...@gmail.com:

I'm concerned about the actual implementation of email, url, tel  
and number.
In shipping versions of Safari (and maybe other browsers ?), those  
are

exposed but without new functionality.


We're working on such functionalities: static validation for type=url
and type=email inputs is on its way, you may be interested in bug
27456 and 27457.

--
Bye,
Michelangelo
Sorry, I wasn't clear enough in my explanation. I was talking about  
functionality such as Adress Book or History connection (for email,  
tel or url) or + and - buttons for numbers. The kind of features that  
web developers expect when input.type != text (like in Opera)

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Anthony Ricaud]

Le 27 août 09 à 00:03, Peter Kasting a écrit :

On Wed, Aug 26, 2009 at 2:59 PM, Anthony Ricaud rik...@gmail.com  
wrote:
Sorry, I wasn't clear enough in my explanation. I was talking about  
functionality such as Adress Book or History connection (for email,  
tel or url) or + and - buttons for numbers. The kind of features  
that web developers expect when input.type != text (like in Opera)


I'm not sure why or how web developers are relying on type=email,  
tel, or URL to have a UA hook to some sort of local address book or  
history.  Why because such behavior is not specced anywhere (and  
is outside the scope of HTML5) and is unlikely to be the same  
between browsers, and how because I don't see how a web author  
would compensate in the case of no type=url support (for example) by  
providing a hand-rolled history list -- that data is not available  
to the author.


PK
For input type=number, Opera and WebKit patches (https://bugs.webkit.org/show_bug.cgi?id=27968 
) provide a UI to help selecting a number. This is something authors  
can provide through JS when it's not handled by the browser. And they  
can only use the DOM type to check for that.


For other types (email, tel, url), sure, authors can't implement  
anything similar. But they can style them differently, offer  
indications on how to fill them, etc. One of the reason to use new  
input types in HTML5 is that they degrade gracefully, offering hooks  
to authors to enhance their pages for browsers not supporting them  
while providing the native version for browsers supporting them.  
That's no longer possible if new types are exposed without new  
functionality.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Canvas API in Webkit

[Anthony Ricaud]

You might be interested in Ariya's experiments with tab preview:

http://ariya.blogspot.com/2008/07/be-my-mirror-my-sword-and-shield.html
http://ariya.blogspot.com/2008/08/seas-would-rise-when-i-gave-words.html

Anthony.

Le 14 déc. 08 à 23:24, Lucius Fox a écrit :


Hi,

Mozilla has a Canvas API which allow extension developer to paint  
the web page content to a surface. So that extension tab preview is  
possible:


http://ted.mielczarek.org/code/mozilla/tabpreview/

Is that the same kind of api in webkit? If yes, can you please tell  
me where i can find example?


Thank you.

___
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] Database Storage

[Anthony Ricaud]

Hi,

The database storage (like cookies, localStorage and sessionStorage)  
is stored locally. So everyone can modify it, you can't rely on it.  
It's really easy to do so with the Database panel in the Web Inspector.

Anthony.

Le 3 oct. 08 à 02:45, Loll a écrit :

 Hi,

 Im not sure if this is the right place to ask this or not, so im sorry
 in advance if it is.

 I am interested in the database Storage that is now available through
 webkit and had a few questions about it.

 My main point of interest is in the security of it. Right now, the
 website I develop uses PHP and information is stored using PHP
 sessions. From a servers point of view I can see a lot of advantages
 of storing such data locally. For one thing , its lot less reads and
 writes to the server, making it a bit faster I would expect.

 But how secure is the data? is it secure enough to reliably put such
 info on a clients system? Im not talking about bank data here, but I
 am looking at data that I would not want to be altered or viewed in
 its raw format all the same.

 Is it safe to assume that no one is going to get into it , any more
 than its safe to assume that no one is going to hijack a PHP Session
 to gain access to the same data?

 Anyway I just wondered if was a good idea to think about moving in the
 direction of local storage vs server storage and what level of data
 should be safely stored that way, vs what shouldn't be stored that  
 way.

 Thanks

 Loll
 ___
 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