<bikeshedding> Just like we don't call the class DOMDocument, there is no need to add the CSS prefix where there aren't collisions (IMO).
I do think we should drop the "WebKit" prefix from all classes, and use InterfaceName= the .idl to map from "InternalName" to "WebKitExternalName". http://trac.webkit.org/wiki/WebKitIDL#InterfaceName </bikeshedding> On Fri, Jul 13, 2012 at 7:17 AM, Andrei Bucur <[email protected]> wrote: > CSSRegion is it then! I'll also make a patch to rename WebKitNamedFlow > into CSSNamedFlow. > > Thx! > Andrei. > > On 7/12/12 10:37 PM, "Alexis Menard" <[email protected]> wrote: > >>So far in the css/ directory we tried to renamed slowly classes so that : >> >>CSS* prefixed classes are the implementation of CSSOM >>"whatevername" is for internal classes. For example we renamed >>CSSStyleApplyProperty class to StyleBuilder because it's internal. >> >>Hope that helps. >> >>On Thu, Jul 12, 2012 at 2:52 PM, Simon Fraser <[email protected]> >>wrote: >>> I'd prefer we keep "Region" for the low-level graphics primitive Region >>> (just like Path), and use something prefixed for the higher-level layout >>> concept. >>> >>> Simon >>> >>> On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote: >>> >>> On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa <[email protected]> wrote: >>>> >>>> I'd vote for CSSRegion or CSSOMRegion for the class you're adding but >>>>I'll >>>> also suggest we rename the existing Region class now that the term >>>>"region" >>>> has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? >>> >>> IntRegion? It seems closer to an IntRect than a LayoutRect. >>>> >>>> - Ryosuke >>>> >>>> On Jul 12, 2012 10:13 AM, "Eric Seidel" <[email protected]> wrote: >>>>> >>>>> I would go with CSSRegion, and stick it in the css/ folder. Much of >>>>> the CSS folder is our implementation of the CSS Object Model (CSSOM). >>>>> At some point it might make sense to pull all the classes which >>>>> implement the CSSOM out of css/ into a new cssom/ similar to dom/, but >>>>> that's a later discussion. >>>>> >>>>> -eric >>>>> >>>>> On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur <[email protected]> >>>>>wrote: >>>>> > From my knowledge the "CSS" prefix is reserved for the CSS engine >>>>> > classes in >>>>> > WebKit. Prefixing the Region class with "CSS" could prove confusing. >>>>> > >>>>> > Regards, >>>>> > Andrei. >>>>> > >>>>> > From: Alan Stearns <[email protected]> >>>>> > Date: Thursday, July 12, 2012 7:39 PM >>>>> > To: Adam Barth <[email protected]>, Andrei Bucur <[email protected]> >>>>> > >>>>> > Cc: "[email protected]" <[email protected]> >>>>> > Subject: Re: [webkit-dev] Web APIs and class name collisions >>>>> > >>>>> > The spec itself consistently and deliberately calls them "CSS >>>>>Regions," >>>>> > so a >>>>> > CSS prefix could be appropriate. >>>>> > >>>>> > Thanks, >>>>> > >>>>> > Alan >>>>> > >>>>> > >>>>> > From: Adam Barth <[email protected]> >>>>> > To: Andrei Bucur <[email protected]> >>>>> > Cc: "[email protected]" <[email protected]> >>>>> > Subject: Re: [webkit-dev] Web APIs and class name collisions >>>>> > >>>>> > One common thing we do is prefix "DOM" to DOM-level concepts. For >>>>> > example, >>>>> > DOMWindow and DOMFileSystem. I'm not sure if we have an established >>>>> > convention for CSS-level concepts. >>>>> > >>>>> > Adam >>>>> > >>>>> > >>>>> > On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur <[email protected]> >>>>>wrote: >>>>> >> >>>>> >> Hello Webkittens! >>>>> >> >>>>> >> While implementing the Region interface ( >>>>> >> http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've >>>>> >> noticed >>>>> >> that the name "Region" is already taken by a class in >>>>> >> platform/graphics. I'd >>>>> >> like to know what's the best approach in these kind of situations: >>>>> >> >>>>> >> Rename the existing WebCore class to something else and use the >>>>>name >>>>> >> "Region" for the Web API so there's parity between the >>>>>implementation >>>>> >> and >>>>> >> the spec >>>>> >> Somehow prefix the Web API implementation class name? >>>>> >> >>>>> >> As the Web APIs expand I suppose this situation may occur again in >>>>>the >>>>> >> future and I suppose there should be a rule describing what's the >>>>>best >>>>> >> approach to take. >>>>> >> >>>>> >> Thanks! >>>>> >> Andrei. >>>>> >> >>>>> >> _______________________________________________ >>>>> >> webkit-dev mailing list >>>>> >> [email protected] >>>>> >> http://lists.webkit.org/mailman/listinfo/webkit-dev >>>>> >> >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > webkit-dev mailing list >>>>> > [email protected] >>>>> > http://lists.webkit.org/mailman/listinfo/webkit-dev >>>>> > >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> [email protected] >>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >> >> >> >>-- >>Alexis Menard (darktears) >>Software Engineer >>openBossa @ INdT - Instituto Nokia de Tecnologia >>_______________________________________________ >>webkit-dev mailing list >>[email protected] >>http://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
