Re: [webkit-dev] Removing ENABLE(DATA_TRANSFER_ITEMS)

2015-12-22 Thread Gyuyoung Kim
> DataTransfer.items is part of the spec, so it seems like we should
support it. Are you saying that the code that's currently in trunk is not
useful enough to help with eventually adding full support?

No, current implementation seems to support the spec. If some ports want to
use it, current implementation is enough to be useful. I meant that the
feature hasn't been maintained for a long time and nobody uses it now. But
if you have a plan to use it in future as well as supporting it, the
current implementation should be kept.

Gyuyoung.

On Wed, Dec 23, 2015 at 2:02 AM, Alexey Proskuryakov <
aproskurya...@gmail.com> wrote:

>
> 21 дек. 2015 г., в 22:02, Gyuyoung Kim 
> написал(а):
>
> It looks like no ports have used a data transfer items feature. Even the
> feature hasn't been updated since 2011. If anyone doesn't have a plan to
> use it in future, I plan to remove it. Any objections ?
>
>
> DataTransfer.items is part of the spec, so it seems like we should support
> it. Are you saying that the code that's currently in trunk is not useful
> enough to help with eventually adding full support?
>
> - Alexey
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Xabier Rodriguez-Calvar and Michael Catanzaro are now WebKit reviewers

2015-12-22 Thread Mark Lam
Hi everyone,

With pleasure, I would like to announce that Xabier Rodriguez-Calvar and 
Michael Catanzaro are now WebKit reviewers.

Congratulations to Xabier and Michael.

Mark

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


Re: [webkit-dev] MathML layout refactor proposal

2015-12-22 Thread Dave Barton
Since I was the one who changed RenderMathMLBlock to derive from RenderFlexibleBox instead of RenderBlock back in 2012, I thought I should reply to the recent question on it and give my reasons for doing so.1. Ideally, we want most webkit developers to not even have to think about MathML. If you make some change to the rendering and layout code and it doesn't break non-MathML layout features, including flexbox, then ideally that should almost always mean that MathML layout is still ok.2. Conversely, it would be ideal if the MathML layout code didn't have to worry about a lot of non-math things - floats, columns, margin collapsing, internal RenderBlock voodoo, etc. We just want good fast MathML layout, that integrates well with HTML, CSS, and _javascript_.3. MathML must introduce few or no bugs, and especially no security bugs.Basically, I think deriving from RenderFlexibleBox helped with all 3 points. Besides helping directly with these points, I think it also allows the MathML implementation to be thousands of lines of code, instead of tens of thousands, which also helps with all 3 points. (I think that also will help with convincing other browser vendors to implement MathML, if and when they consider doing so.) At the end of 2012, the webkit MathML code was around 2,500 lines (admittedly it didn't implement all of MathML). In comparison, the MathPlayer plugin for Internet Explorer, MathML implementation inside Gecko, and the MathJax _javascript_ library, were each about 20,000-40,000+ lines of code. Another comparison is that the webkit rendering/svg source code folder then contained about 17,700 lines. If we try to implement MathML from scratch, sort of like SVG, then I think it will take many developer-years to do, which frankly may never happen.Gecko MathML doesn't use flexbox, but that's because flexbox didn't exist when Gecko's MathML code was orginally written. Another point is that webkit MathML's use of anonymous blocks predates its use of flexbox, and is somewhat independent of it. Finally, using flexbox (and also anonymous blocks) had nothing to do with Google's decision to turn off MathML, and eventually delete the code.From http://www.w3.org/TR/css-flexbox-1/#overview we have:Flex layout is superficially similar to block layout. It lacks many of the more complex text- or document-centric properties that can be used in block layout, such as floats and columns [and margin collapsing]. In return it gains simple and powerful tools for distributing space and aligning content in ways that webapps and complex web pages often need. The contents of a flex container:can be laid out in any flow direction (leftwards, rightwards, downwards, or even upwards!)can have their display order reversed or rearranged at the style layer (i.e., visual order can be independent of source and speech order)can be laid out linearly along a single (main) axis or wrapped into multiple lines along a secondary (cross) axiscan “flex” their sizes to respond to the available spacecan be aligned with respect to their container or each othercan be dynamically collapsed or uncollapsed along the main axis while preserving the container’s cross sizeMathML may not absolutely need all these, but several (like changing the order for mroot) are very useful, and outlawing floats and columns and margin collapsing is great for avoiding bugs or unintended interactions with other code. So again by using flexbox, I think MathML can be thousands of lines instead of tens of thousands of lines, and will need a lot less new tricky lines to avoid buggy interactions with existing layout features and voodoo.Finally, I'd like to say that I think it's great that you guys are asking for feedback on this. There are obviously webkit layout and rendering experts that know a lot more than I do, and I urge you very strongly to try to get one of them to help you with this design decision. Otherwise someone else in a few years may delete your code, as has happened to me. :)___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] MathML layout refactor proposal

2015-12-22 Thread dbarton
2nd try - hopefully as raw text, not an html attachment this time:

Since I was the one who changed RenderMathMLBlock to derive from 
RenderFlexibleBox instead of RenderBlock back in 2012, I thought I should reply 
to the recent question on it and give my reasons for doing so.

1. Ideally, we want most webkit developers to not even have to think about 
MathML. If you make some change to the rendering and layout code and it doesn't 
break non-MathML layout features, including flexbox, then ideally that should 
almost always mean that MathML layout is still ok.

2. Conversely, it would be ideal if the MathML layout code didn't have to worry 
about a lot of non-math things - floats, columns, margin collapsing, internal 
RenderBlock voodoo, etc. We just want good fast MathML layout, that integrates 
well with HTML, CSS, and JavaScript.

3. MathML must introduce few or no bugs, and especially no security bugs.

Basically, I think deriving from RenderFlexibleBox helped with all 3 points. 
Besides helping directly with these points, I think it also allows the MathML 
implementation to be thousands of lines of code, instead of tens of thousands, 
which also helps with all 3 points. (I think that also will help with 
convincing other browser vendors to implement MathML, if and when they consider 
doing so.) At the end of 2012, the webkit MathML code was around 2,500 lines 
(admittedly it didn't implement all of MathML). In comparison, the MathPlayer 
plugin for Internet Explorer, MathML implementation inside Gecko, and the 
MathJax javascript library, were each about 20,000-40,000+ lines of code. 
Another comparison is that the webkit rendering/svg source code folder then 
contained about 17,700 lines. If we try to implement MathML from scratch, sort 
of like SVG, then I think it will take many developer-years to do, which 
frankly may never happen.

Gecko MathML doesn't use flexbox, but that's because flexbox didn't exist when 
Gecko's MathML code was orginally written. Another point is that webkit 
MathML's use of anonymous blocks predates its use of flexbox, and is somewhat 
independent of it. Finally, using flexbox (and also anonymous blocks) had 
nothing to do with Google's decision to turn off MathML, and eventually delete 
the code.

From http://www.w3.org/TR/css-flexbox-1/#overview we have:

Flex layout is superficially similar to block layout. It lacks many of the more 
complex text- or document-centric properties that can be used in block layout, 
such as floats and columns [and margin collapsing]. In return it gains simple 
and powerful tools for distributing space and aligning content in ways that 
webapps and complex web pages often need. The contents of a flex container:

can be laid out in any flow direction (leftwards, rightwards, downwards, or 
even upwards!)

can have their display order reversed or rearranged at the style layer (i.e., 
visual order can be independent of source and speech order)

can be laid out linearly along a single (main) axis or wrapped into multiple 
lines along a secondary (cross) axis

can “flex” their sizes to respond to the available space

can be aligned with respect to their container or each other

can be dynamically collapsed or uncollapsed along the main axis while 
preserving the container’s cross size

MathML may not absolutely need all these, but several (like changing the order 
for mroot) are very useful, and outlawing floats and columns and margin 
collapsing is great for avoiding bugs or unintended interactions with other 
code. So again by using flexbox, I think MathML can be thousands of lines 
instead of tens of thousands of lines, and will need a lot less new tricky 
lines to avoid buggy interactions with existing layout features and voodoo.

Finally, I'd like to say that I think it's great that you guys are asking for 
feedback on this. There are obviously webkit layout and rendering experts that 
know a lot more than I do, and I urge you very strongly to try to get one of 
them to help you with this design decision. Otherwise someone else in a few 
years may delete your code, as has happened to me. :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev