Re: [webkit-dev] Formatting style for inline comments in Python code

2017-10-25 Thread Michael Catanzaro
On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain  
wrote:

Does anyone else has any opinion/preference for this?


The number of spaces before a comment really does not matter, but my 
$0.02: PEP8 is an extremely common style for Python programs that all 
Python developers are familiar with. I would follow that, and forget 
about trying to adapt WebKit C++ style to an unrelated language. Trying 
to adapt the style checker to ignore particular PEP8 rules seems like 
wasted effort.


Michael

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


Re: [webkit-dev] Formatting style for inline comments in Python code

2017-10-25 Thread Aakash Jain
As Ryosuke said, we can modify check-webkit-style and in-fact I will update 
that if we decide to use Webkit style for this case.

Does anyone else has any opinion/preference for this?

Thanks
Aakash


> On Oct 25, 2017, at 12:22 PM, Brian Burg  wrote:
> 
> In this case, I always prefer the PEP8 rules, because check-webkit-style will 
> complain if you don't do so.
> 
> Brian
> 
>> 2017/10/25 午後0:13、Aakash Jain > >のメール:
>> 
>> Hi All,
>> 
>> There is one case in which Webkit style guidelines and Python style 
>> guidelines do not match. This is about spacing before inline comments.
>> 
>> WebKit style guidelines 
>> (https://webkit.org/code-style-guidelines/#comments-eol 
>> ) says: "Use only 
>> one space before end of line comments and in between sentences in comments."
>> 
>> Python PEP8 style guidelines 
>> (https://www.python.org/dev/peps/pep-0008/#inline-comments 
>> ) says: "Inline 
>> comments should be separated by at least two spaces from the statement."
>> 
>> Should we use "one space" or "two spaces" before the inline comments in 
>> python code inside Webkit?
>> 
>> Thanks
>> Aakash
>> 
>> Reference: https://bugs.webkit.org/show_bug.cgi?id=171506 
>> ___
>> 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] Touch Bar Web API

2017-10-25 Thread Theresa O'Connor
Hi,

Aishwarya wrote:

>> I am working on a Touch Bar Web API that would allow websites to
>> customize touch bar controls. There is currently no web standard for
>> an interface like the touch bar, so my plan is to experiment with
>> this feature and gather feedback that can inform a web standard.
>>
>> We have a fairly solid plan for how we want to go forward with this.
>> We are planning to make use of the existent menu and menuitem tags to
>> define the touch bar and touch bar items, respectively. The menu will
>> be recognized as a touch bar menu if it has the type attribute
>> “touch-bar”, and its contents would be rendered in the touch bar.
>>
>> I will be posting and landing patches under an experimental feature
>> flag. The umbrella bug on Bugzilla can be found here:
>> https://bugs.webkit.org/show_bug.cgi?id=178736 .

Anne replied:

> Heya, I'd appreciate it if you could give the HTML Standard community
> a heads up about using the "touch-bar" value.

We'll propose specific spec changes once we know what they'll be. The
work behind this flag is how we'll figure out what to ask for.


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


Re: [webkit-dev] Formatting style for inline comments in Python code

2017-10-25 Thread Ryosuke Niwa
On Wed, Oct 25, 2017 at 12:22 PM, Brian Burg  wrote:

> In this case, I always prefer the PEP8 rules, because check-webkit-style
> will complain if you don't do so.
>
> Brian
>

It's not like we can't fix the style checker. We also follow the usual
WebKit style guidelines in other places like indentations. Instead of
aligning the beginning of each line, we indent by exactly four spaces.

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


Re: [webkit-dev] Formatting style for inline comments in Python code

2017-10-25 Thread Ryosuke Niwa
We should probably use one space to be consistent across the project.

- R. Niwa

On Wed, Oct 25, 2017 at 12:13 PM, Aakash Jain  wrote:

> Hi All,
>
> There is one case in which Webkit style guidelines and Python style
> guidelines do not match. This is about spacing before inline comments.
>
> WebKit style guidelines (https://webkit.org/code-
> style-guidelines/#comments-eol) says: "Use only *one* *space* before end
> of line comments and in between sentences in comments."
>
> Python PEP8 style guidelines (https://www.python.org/dev/
> peps/pep-0008/#inline-comments) says: "Inline comments should be
> separated by at least *two spaces* from the statement."
>
> Should we use "one space" or "two spaces" before the inline comments in
> python code inside Webkit?
>
> Thanks
> Aakash
>
> Reference: https://bugs.webkit.org/show_bug.cgi?id=171506
>
> ___
> 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] Formatting style for inline comments in Python code

2017-10-25 Thread Brian Burg
In this case, I always prefer the PEP8 rules, because check-webkit-style will 
complain if you don't do so.

Brian

> 2017/10/25 午後0:13、Aakash Jain のメール:
> 
> Hi All,
> 
> There is one case in which Webkit style guidelines and Python style 
> guidelines do not match. This is about spacing before inline comments.
> 
> WebKit style guidelines 
> (https://webkit.org/code-style-guidelines/#comments-eol 
> ) says: "Use only one 
> space before end of line comments and in between sentences in comments."
> 
> Python PEP8 style guidelines 
> (https://www.python.org/dev/peps/pep-0008/#inline-comments 
> ) says: "Inline 
> comments should be separated by at least two spaces from the statement."
> 
> Should we use "one space" or "two spaces" before the inline comments in 
> python code inside Webkit?
> 
> Thanks
> Aakash
> 
> Reference: https://bugs.webkit.org/show_bug.cgi?id=171506 
> ___
> 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] Formatting style for inline comments in Python code

2017-10-25 Thread Aakash Jain
Hi All,

There is one case in which Webkit style guidelines and Python style guidelines 
do not match. This is about spacing before inline comments.

WebKit style guidelines (https://webkit.org/code-style-guidelines/#comments-eol 
) says: "Use only one 
space before end of line comments and in between sentences in comments."

Python PEP8 style guidelines 
(https://www.python.org/dev/peps/pep-0008/#inline-comments 
) says: "Inline 
comments should be separated by at least two spaces from the statement."

Should we use "one space" or "two spaces" before the inline comments in python 
code inside Webkit?

Thanks
Aakash

Reference: https://bugs.webkit.org/show_bug.cgi?id=171506
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Web App Manifest Standard

2017-10-25 Thread David Quesada

> On Oct 24, 2017, at 5:19 PM, Michael Catanzaro  wrote:
> 
> 
> Hi David,
> 
> If this is implemented in WebKit, how do you envision applications should 
> consume the information?

The manifest would primarily be used when the user installs and later launches 
a web app, but some of its metadata (short_name, description, icons, 
theme_color, background_color) could have other uses.

> Do you plan to add API for Safari to use to access the web app metadata? If 
> so, cool: we might follow up with a corresponding GLib API, since that would 
> be useful for the GTK and WPE ports as well. If not, how do you plan for this 
> to work?

I’m going to start by exposing these functionalities to applications:

1. Add API on the top-level browsing context to fetch the metadata and provide 
it to the application (i.e. run the steps at 
https://www.w3.org/TR/appmanifest/#dfn-steps-for-obtaining-a-manifest 
 then 
invoke a callback function with a manifest object) The exact time this fetch 
happens is up to the implementation to decide.
2. Add API for specifying an application manifest to apply when creating a new 
top-level browsing context. This is needed since some properties of the 
manifest can affect the behavior of the web content. (This would likely be 
added as a new property on WKWebViewConfiguration, I’m not sure what the 
equivalent is for other ports.) This API would be used when setting up the web 
view when a user opens a web app.

- David

> 
> Michael
> 

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


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-25 Thread Michael Catanzaro
On Wed, Oct 25, 2017 at 12:05 PM, Maciej Stachowiak  
wrote:
Why don't we wait to hear from port owners whether they would 
actually want to disable MathML for reason of compatibiltiy. Knowing 
answers to the above questions would help.


For GTK and WPE, I think it's fine to have MathML enabled 
unconditionally.


Michael

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


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-25 Thread Frédéric WANG
On 25/10/2017 19:05, Maciej Stachowiak wrote:
>
> (1) Is it at all common to use MathML with a math font specified as a web 
> font? Can you give an example?
I can't say whether it is "common" but I guess the trick is well known
by MathML users, since unfortunately many systems do not provide math
fonts by default. I have a github repo with known fonts at
https://github.com/fred-wang/MathFonts

As an example Jacques Distler uses STIX 2 WOFF on his blog:

https://golem.ph.utexas.edu/~distler/blog/archives/002702.html
https://golem.ph.utexas.edu/~distler/blog/styles-site.css

Some people also bundle WOFF fonts in web apps or ebooks. Web fonts are
also used by browser addons e.g.
https://addons.mozilla.org/en-US/firefox/addon/mathml-fonts/ which allow
to workaround the lack of system fonts (and the impossibility to install
them for users).

Website using MathML often have a page with installation instructions
for math fonts, for example on NIST dlmf:
http://dlmf.nist.gov/help/mathml#S3

Note that I've seen similar things (WOFF fonts, addons, instructions)
for other languages in the past e.g.
https://addons.mozilla.org/en-US/firefox/addon/khmer-fonts-package/, so
again it's not specific to math.

> (2) Is it at all common to use MathML only to the extent that it's rendered 
> fine without a math font?
Again, I'm not sure how common it is but I've seen some users happy with
basic MathML rendering for elementary calculations. I was also surprised
to see some people excited about my CSS stylesheet at
https://github.com/fred-wang/mathml.css that can render very basic math.
There are a lot of such formulas on Wikipedia, for sure for instance
https://en.wikipedia.org/wiki/Fraction_(mathematics) contains MathML
formulas that can be rendered without specialized math fonts.
> (3) In the cases above, is there usually an image fallback?
It really depends on the website. But definitely people using MathML
need some fallback (image, CSS layout, javascript layout, text etc).

How this fallback is triggered depends on the website, there is not any
real rule. IIUC, the argument mentioned earlier only considers the case
where an author would try to detect MathML support and automatically
fallback to an image otherwise. As I said, authors could also try to
detect availability of math fonts, or provide WOFF fallback (Distler's
blog), or have a page to explain how to install fonts (e.g. NIST dlmf),
or use image by default and explain how to enable MathML & install fonts
(e.g. Wikipedia), or provide LaTeX fallback in an  (my blog)
or...

IMHO, platform owners should not speculate on what authors will do.
Disabling MathML just because of the lack of math fonts, does not seem a
good idea. On the one hand, if MathML is enabled page authors can still
decide to serve fallback content if they think the support is not good
enough on the user platform. On the other hand, if the platform owner
has disabled MathML, then there is no way for users/authors willing to
use MathML to force it to be enabled again...
> Why don't we wait to hear from port owners whether they would actually want 
> to disable MathML for reason of compatibiltiy. Knowing answers to the above 
> questions would help.
Sure. My email was to follow-up on
https://bugs.webkit.org/show_bug.cgi?id=177744 and the discussions at
the Web Engines Hackfest, so they are not forgotten. But there is no
hurry to remove the build flag for now.

-- 
Frédéric Wang - frederic-wang.fr




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


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-25 Thread Maciej Stachowiak


> On Oct 25, 2017, at 1:44 AM, Frédéric WANG  wrote:
> 
> On 24/10/2017 18:50, Maciej Stachowiak wrote:
>> I don't have a strong opinion on whether we should support disabling
>> MathML. My point is just that if we support disabling it, it should be
>> a runtime switch, not compile-time.
>> Good reasons to have a compile-time switch would be:
>> - Some ports want the code size savings
>> - It requires back-end code that is not available on all ports
>> 
>> But neither of those is true.
>> 
>> On the other hand, we might still want a runtime switch if some ports would 
>> like to disable the feature for reason of compatibility based on available 
>> fonts. I think it's up to port owners to say whether they want to disable 
>> the feature for this reason.
> Hi,
> 
> I believe it is up to the platform owners to decide whether they want to
> provide math fonts by default ; depending on whether they want to
> privilege disk space or a better user experience.
> 
> However, I still don't see the connection between available fonts and
> enabling MathML support. As I said, some pages with MathML provide the
> necessary WOFF math fonts while others just use basic math (fractions
> etc) where the default text fonts are enough. So the owners would be
> intentionally breaking these pages, just because they don't provide math
> fonts on their platforms ? That sounds weird, to me.

(1) Is it at all common to use MathML with a math font specified as a web font? 
Can you give an example?

(2) Is it at all common to use MathML only to the extent that it's rendered 
fine without a math font?

(3) In the cases above, is there usually an image fallback?

Why don't we wait to hear from port owners whether they would actually want to 
disable MathML for reason of compatibiltiy. Knowing answers to the above 
questions would help.


> 
> Also I think a runtime flag makes sense for the use case of the Tor
> project, but it is a separate use case IMHO and it should not be
> blocking the removal of the compile-time flag.
> 
> So to summarize, I'm happy to submit a patch to remove ENABLE(MATHML) if
> the only reasons were the two points you mention (which as you said are
> not true here). However, if some port owners provide a concrete
> explanation of why they want to keep the option of disabling MathML then
> I don't think I'll have time to check the runtime option right now, so
> I'll just keep the status quo and it will be up to these people to
> submit a patch or to keep fixing the build failures for --no-mathml ;-)
> 
> -- 
> Frédéric Wang - frederic-wang.fr
> 
> 

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


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-25 Thread Frédéric WANG
On 24/10/2017 18:50, Maciej Stachowiak wrote:
> I don't have a strong opinion on whether we should support disabling
> MathML. My point is just that if we support disabling it, it should be
> a runtime switch, not compile-time.
> Good reasons to have a compile-time switch would be:
> - Some ports want the code size savings
> - It requires back-end code that is not available on all ports
>
> But neither of those is true.
>
> On the other hand, we might still want a runtime switch if some ports would 
> like to disable the feature for reason of compatibility based on available 
> fonts. I think it's up to port owners to say whether they want to disable the 
> feature for this reason.
Hi,

I believe it is up to the platform owners to decide whether they want to
provide math fonts by default ; depending on whether they want to
privilege disk space or a better user experience.

However, I still don't see the connection between available fonts and
enabling MathML support. As I said, some pages with MathML provide the
necessary WOFF math fonts while others just use basic math (fractions
etc) where the default text fonts are enough. So the owners would be
intentionally breaking these pages, just because they don't provide math
fonts on their platforms ? That sounds weird, to me.

Also I think a runtime flag makes sense for the use case of the Tor
project, but it is a separate use case IMHO and it should not be
blocking the removal of the compile-time flag.

So to summarize, I'm happy to submit a patch to remove ENABLE(MATHML) if
the only reasons were the two points you mention (which as you said are
not true here). However, if some port owners provide a concrete
explanation of why they want to keep the option of disabling MathML then
I don't think I'll have time to check the runtime option right now, so
I'll just keep the status quo and it will be up to these people to
submit a patch or to keep fixing the build failures for --no-mathml ;-)

-- 
Frédéric Wang - frederic-wang.fr




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


Re: [webkit-dev] Touch Bar Web API

2017-10-25 Thread Anne van Kesteren
On Tue, Oct 24, 2017 at 8:46 PM, Aishwarya Nirmal  wrote:
> I am working on a Touch Bar Web API that would allow websites to customize
> touch bar controls. There is currently no web standard for an interface like
> the touch bar, so my plan is to experiment with this feature and gather
> feedback that can inform a web standard.
>
> We have a fairly solid plan for how we want to go forward with this. We are
> planning to make use of the existent menu and menuitem tags to define the
> touch bar and touch bar items, respectively. The menu will be recognized as
> a touch bar menu if it has the type attribute “touch-bar”, and its contents
> would be rendered in the touch bar.
>
> I will be posting and landing patches under an experimental feature flag.
> The umbrella bug on Bugzilla can be found here:
> https://bugs.webkit.org/show_bug.cgi?id=178736 .

Heya, I'd appreciate it if you could give the HTML Standard community
a heads up about using the "touch-bar" value. Seems reasonable at
first glance, but would be nice to ensure nobody gets surprised:
https://github.com/whatwg/html/issues/new.

Thanks,


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