Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?
On Dec 21, 2012, at 3:06 PM, Elliott Sprehn wrote: > > On Fri, Dec 21, 2012 at 6:09 AM, Antti Koivisto wrote: > On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. wrote: > No, it's just a refactoring on the CSS side, so we don't have to > repeat a bunch of stuff every time we have an at-rule that contains > other rules. It just makes the WebIDL easier and less error-prone. > > It seems bit strange to add a web-exposed type if it is just a spec writing > helper. Each new type has non-zero cost (code size of generated bindings etc). > > Internally it obviously makes sense to share code, I'm just wondering why we > would want to expose this via API. > > > It means you can add methods to the prototype across all the types, and you > can override methods across the types per the way they're described in IDL. > It also provides instanceof for type checking in JS. Prototype hacking the CSSOM and instanceof-based dynamic type checking of the CSSOM are both pretty improbable use cases. > > If we're not going to expose it and be spec compliant then perhaps we should > take that up with the spec as an objection and see if they're willing to use > a NoInterfaceObject instead. I think you would probably also want it to be a supplemental interface to achieve the desired effect, if going this route. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?
On Fri, Dec 21, 2012 at 6:09 AM, Antti Koivisto wrote: > On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. wrote: > >> No, it's just a refactoring on the CSS side, so we don't have to >> repeat a bunch of stuff every time we have an at-rule that contains >> other rules. It just makes the WebIDL easier and less error-prone. >> > > It seems bit strange to add a web-exposed type if it is just a spec > writing helper. Each new type has non-zero cost (code size of generated > bindings etc). > > Internally it obviously makes sense to share code, I'm just wondering why > we would want to expose this via API. > > It means you can add methods to the prototype across all the types, and you can override methods across the types per the way they're described in IDL. It also provides instanceof for type checking in JS. If we're not going to expose it and be spec compliant then perhaps we should take that up with the spec as an objection and see if they're willing to use a NoInterfaceObject instead. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?
On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. wrote: > No, it's just a refactoring on the CSS side, so we don't have to > repeat a bunch of stuff every time we have an at-rule that contains > other rules. It just makes the WebIDL easier and less error-prone. > It seems bit strange to add a web-exposed type if it is just a spec writing helper. Each new type has non-zero cost (code size of generated bindings etc). Internally it obviously makes sense to share code, I'm just wondering why we would want to expose this via API. antti > > ~TJ > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?
On Thu, Dec 13, 2012 at 2:12 PM, Antti Koivisto wrote: > We already have internal type corresponding to the new CSSGroupingRule, > StyleRuleBlock. Technically refactoring the CSSOM like this would be fairly > trivial. > > It is not clear to me what value this new type adds though. In JS you don't > really care if types have a common base as long as they share similar > looking interface. Are there some concrete use cases? No, it's just a refactoring on the CSS side, so we don't have to repeat a bunch of stuff every time we have an at-rule that contains other rules. It just makes the WebIDL easier and less error-prone. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?
On Thu, 13 Dec 2012 14:12:06 -0800, Antti Koivisto wrote: We already have internal type corresponding to the new CSSGroupingRule, StyleRuleBlock. Technically refactoring the CSSOM like this would be fairly trivial. It is not clear to me what value this new type adds though. In JS you don't really care if types have a common base as long as they share similar looking interface. Are there some concrete use cases? Not particularly, no, i just saw a lot of copypasting around cssRules/insertRule/deleteRule/cssomwrappers. I don't feel strongly about this, so i can leave it alone, maybe post a patch later on if have the time, to see if it would add value. Thanks for the input, /pf antti On Thu, Dec 13, 2012 at 3:41 AM, Pablo Flouret wrote: Hello webkit folk, I'm working on having @supports behave like a proper CSSSupportsRule [1]. In the css3-conditional spec, CSSSupportsRule inherits from a CSSGroupingRule (CSSMediaRule does as well): http://dev.w3.org/csswg/css3-conditional/#the-cssgroupingrule-interface. I'm wondering if it's a good idea, as a first step, to do a bit of refactoring and rip the stuff that's now in CSSGroupingRule from CSSMediaRule (cssRules/insertRule/deleteRule), and have the supports and media rules inherit from it. Incidentally, i see at least WebKitCSSKeyframesRule and WebKitCSSRegionRule also having similar but not quite identical re-implementations of these functions, but i guess whether these ones should also inherit from CSSGroupingRule might be a question for the standards mailing lists first (in any case, they would potentially benefit from such a refactoring). Opinions / advice / potential problems? Thanks! [1] http://wkbug.com/104822 -- pablo flouret motorola | webkit / browser team ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- pablo flouret motorola | webkit / browser team ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?
We already have internal type corresponding to the new CSSGroupingRule, StyleRuleBlock. Technically refactoring the CSSOM like this would be fairly trivial. It is not clear to me what value this new type adds though. In JS you don't really care if types have a common base as long as they share similar looking interface. Are there some concrete use cases? antti On Thu, Dec 13, 2012 at 3:41 AM, Pablo Flouret wrote: > Hello webkit folk, > > I'm working on having @supports behave like a proper CSSSupportsRule [1]. > > In the css3-conditional spec, CSSSupportsRule inherits from a > CSSGroupingRule (CSSMediaRule does as well): > http://dev.w3.org/csswg/css3-conditional/#the-cssgroupingrule-interface. > > I'm wondering if it's a good idea, as a first step, to do a bit of > refactoring and rip the stuff that's now in CSSGroupingRule from > CSSMediaRule (cssRules/insertRule/deleteRule), and have the supports > and media rules inherit from it. > > Incidentally, i see at least WebKitCSSKeyframesRule and > WebKitCSSRegionRule also having similar but not quite identical > re-implementations of these functions, but i guess whether these ones > should also inherit from CSSGroupingRule might be a question for the > standards mailing lists first (in any case, they would potentially > benefit from such a refactoring). > > Opinions / advice / potential problems? > > Thanks! > > [1] http://wkbug.com/104822 > > -- > pablo flouret > motorola | webkit / browser team > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSSGroupingRule and a bit of refactoring?
Hello webkit folk, I'm working on having @supports behave like a proper CSSSupportsRule [1]. In the css3-conditional spec, CSSSupportsRule inherits from a CSSGroupingRule (CSSMediaRule does as well): http://dev.w3.org/csswg/css3-conditional/#the-cssgroupingrule-interface. I'm wondering if it's a good idea, as a first step, to do a bit of refactoring and rip the stuff that's now in CSSGroupingRule from CSSMediaRule (cssRules/insertRule/deleteRule), and have the supports and media rules inherit from it. Incidentally, i see at least WebKitCSSKeyframesRule and WebKitCSSRegionRule also having similar but not quite identical re-implementations of these functions, but i guess whether these ones should also inherit from CSSGroupingRule might be a question for the standards mailing lists first (in any case, they would potentially benefit from such a refactoring). Opinions / advice / potential problems? Thanks! [1] http://wkbug.com/104822 -- pablo flouret motorola | webkit / browser team ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
