Re: [webkit-dev] Easy bugs for grab
On 23/09/14 10:28, Benjamin Poulain wrote: -Unprefix your favorite CSS property (easy to hard depending on the property). What's the policy for unprefixing properties? I thought that they're prefixed as long as the feature was experimental/under heavy development. Has it changed? (I'm particularly interested in unprefixing grid layout properties). BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefixing CSS Grid (was: Easy bugs for grab)
On 9/25/14, 12:34 AM, Sergio Villar Senin wrote: On 23/09/14 10:28, Benjamin Poulain wrote: -Unprefix your favorite CSS property (easy to hard depending on the property). What's the policy for unprefixing properties? I thought that they're prefixed as long as the feature was experimental/under heavy development. Has it changed? (I'm particularly interested in unprefixing grid layout properties). The policies have not changed. From the data I have at the moment, I see a few reasons to keep the prefix on Grid Layout: -It is a major feature. -The spec is still a working draft, you are still helping the editor finishing the work. -As far as I know, nobody has shipped the unprefixed version yet, there is no urgency for compatibility. -What IE ships is not the current spec. -I have not seen much feedback from web developers, which is frustrating/annoying :( Once we are fully matching the latest spec and we have outstanding test coverage, we should unprefix the feature. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Type checking / casting helpers
Hi all, I started working on automatically generating the type casting helpers for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until now, we were generating only the type checking helpers using make_names.pl (e.g. isHTMLDivElement()). The type casting helpers had to be manually defined using NODE_TYPE_CASTS() macro. The type casting helpers are now automatically generated for most types. Part of the solution involved using a templated function for type casting because the types are forward-declared and we needed to do a static_cast() (a reinterpret_cast() could be used with forward declarations but wouldn’t be safe due to multiple inheritance). I initially had macros in place so that toHTMLDivElement() would still work and would be equivalent to downcastHTMLDivElement(). The feedback I received is that we should get rid of these macros and just use isHTMLDivElement() / downcastHTMLDivElement() everywhere. The new style is very close to C++’s is_classT() and Boost’s polymorphic_downcastT(). I actually started updating the code to do this but I should have emailed webkit-dev about this beforehand. I apologize for sending this message a bit late. Please let me know if you have feedback / concerns / questions about this change. I hope that this email gives you a better understanding of why I am making this change. As I said before, the code base is not fully ported yet so the current situation is not necessarily pretty. I will try and go through the transition as fast as I can, provided that people don’t raise any concerns about this. Please also note that these new helpers still catch unnecessary type checks / casts. As a matter of fact, those are now caught at build time instead of linking time and should give you a nice “Unnecessary type check” / “Unnecessary type cast” static assertion. Also note that the plan is to get rid of TYPE_CAST_BASE() macro entirely and extend is() / downcast() to all types, not just Nodes. Kr, -- Chris Dumez - Apple Inc. Cupertino, CA ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebView and User Interface Restore
On Sep 21, 2014, at 7:48 PM, Daryle Walker dary...@mac.com wrote: Do WebView instances participate in the Resume feature (with +restoreWindowWithIdentifier: state: completionHandler:, etc.), or do I have to manually handle their state (the web-view’s back-forward list and which item is current) myself? I had to turn Resume back on before trying out. My code to bring back the windows worked, but there was nothing in them. I guess WebKit does not do state save/restore and apps like Safari do it manually. Is there any part of that wrong? Any hints on doing it manually? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fooling with EWS and commit queue
Hi, I started making changes to the logic of EWS and commit queue, please e-mail me if something breaks, or even if something begins to behave more strangely than it did before. - Alexey ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
