Bug 33940 - Address last round of review comments on r53607
Summary: Address last round of review comments on r53607
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-20 23:26 PST by Adam Barth
Modified: 2010-02-10 23:32 PST (History)
2 users (show)

See Also:


Attachments
Patch (16.75 KB, patch)
2010-02-10 01:27 PST, Adam Barth
no flags Details | Formatted Diff | Diff
Patch for landing (16.75 KB, patch)
2010-02-10 17:50 PST, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2010-01-20 23:26:10 PST
> +    // Notice that this object inherits a baseURL function from StyleBase that
> +    // crawls the parent() relation looking for a non-0 putativeBaseURL.
> +    const KURL& putativeBaseURL() const { return m_baseURL; }

It's good to distinguish these two functions. The name putativeBaseURL doesn't
seem to helpfully make it clear which of the two to call, though. The two
differences seem to be:

    1) The putativeBaseURL function is a bit faster than baseURL.
    2) The putativeBaseURL function returns null when m_baseURL is null rather
than climbing to the parent sheet.

Are there any callers that need either behavior (1) or (2) other than
StyleBase::baseURL itself? If not, maybe we can find a way to avoid the
putativeBaseURL function entirely.

> -                m_sheet = XSLStyleSheet::createEmbedded(this, m_localHref);
> +                KURL baseURL = KURL(ParsedURLString, m_localHref);
> +                m_sheet = XSLStyleSheet::createEmbedded(this, m_localHref, baseURL);

Seems to me that CSSStyleSheet::createInline and XSLStyleSheet::createEmbedded
are doing the same thing, for the two different types of stylesheet. Which
leads me to ask:

    1) Why do they have different names?
    2) Why does XSLStyleSheet take two arguments instead of the one that
Document::createInline does?

> -            m_sheet = CSSStyleSheet::create(e, String(), document->inputEncoding());
> +            m_sheet = CSSStyleSheet::create(e, String(), KURL(), document->inputEncoding());

Why not use createInline here?

> +            stylesheetRootNode->document()->url()); // FIXME: Should we use baseURL here?

> +            node->document()->url()); // FIXME: Should we use baseURL here?

I'd like to ask an XSL expert (Alexey?) to help us figure out how to test these
or what is correct.

Although we are stuck with the name "href" for the DOM function, I would have
preferred to use the name "originalURL" everywhere else, since "href" is not
sufficiently unambiguous.
Comment 1 Adam Barth 2010-02-10 00:58:08 PST
(In reply to comment #0)
> > +    // Notice that this object inherits a baseURL function from StyleBase that
> > +    // crawls the parent() relation looking for a non-0 putativeBaseURL.
> > +    const KURL& putativeBaseURL() const { return m_baseURL; }
> 
> It's good to distinguish these two functions. The name putativeBaseURL doesn't
> seem to helpfully make it clear which of the two to call, though. The two
> differences seem to be:
> 
>     1) The putativeBaseURL function is a bit faster than baseURL.
>     2) The putativeBaseURL function returns null when m_baseURL is null rather
> than climbing to the parent sheet.
> 
> Are there any callers that need either behavior (1) or (2) other than
> StyleBase::baseURL itself? If not, maybe we can find a way to avoid the
> putativeBaseURL function entirely.

Turns out there are a bunch of clients.  However, the name "finalURL" seems more appropriate for what these clients want, so I've renamed the whole concept to finalURL.  The baseURL is computed as before, taking into account the parent sheets.

> > -                m_sheet = XSLStyleSheet::createEmbedded(this, m_localHref);
> > +                KURL baseURL = KURL(ParsedURLString, m_localHref);
> > +                m_sheet = XSLStyleSheet::createEmbedded(this, m_localHref, baseURL);
> 
> Seems to me that CSSStyleSheet::createInline and XSLStyleSheet::createEmbedded
> are doing the same thing, for the two different types of stylesheet. Which
> leads me to ask:

These are, in fact, the same concept.  createEmbedded had one client, so I've renamed is to createInline.

>     1) Why do they have different names?

Because I originally thought they were different, but they're not.

>     2) Why does XSLStyleSheet take two arguments instead of the one that
> Document::createInline does?

They should both take one argument.  I've fixed this.

> > -            m_sheet = CSSStyleSheet::create(e, String(), document->inputEncoding());
> > +            m_sheet = CSSStyleSheet::create(e, String(), KURL(), document->inputEncoding());
> 
> Why not use createInline here?

Done.

> > +            stylesheetRootNode->document()->url()); // FIXME: Should we use baseURL here?
> 
> > +            node->document()->url()); // FIXME: Should we use baseURL here?
> 
> I'd like to ask an XSL expert (Alexey?) to help us figure out how to test these
> or what is correct.
> 
> Although we are stuck with the name "href" for the DOM function, I would have
> preferred to use the name "originalURL" everywhere else, since "href" is not
> sufficiently unambiguous.

I've renamed this to originalURL.

Will post a patch shortly.
Comment 2 Adam Barth 2010-02-10 01:10:04 PST
>>> -            m_sheet = CSSStyleSheet::create(e, String(), document->inputEncoding());
>>> +            m_sheet = CSSStyleSheet::create(e, String(), KURL(), document->inputEncoding());
>> 
>> Why not use createInline here?
> 
> Done.

I lied.  This needs to pass in the inputEncoding.  We could make a createInline that takes an input encoding, but it might not be worthwhile for this one call site.
Comment 3 Adam Barth 2010-02-10 01:27:50 PST
Created attachment 48473 [details]
Patch
Comment 4 Darin Adler 2010-02-10 12:38:18 PST
Comment on attachment 48473 [details]
Patch

> +                KURL finalURL = KURL(ParsedURLString, m_localHref);

Syntax here is a little strange. It should just be a constructor rather than looking like an assignment statement.

r=me
Comment 5 Adam Barth 2010-02-10 17:50:51 PST
Created attachment 48534 [details]
Patch for landing
Comment 6 WebKit Commit Bot 2010-02-10 23:32:14 PST
Comment on attachment 48534 [details]
Patch for landing

Clearing flags on attachment: 48534

Committed r54645: <http://trac.webkit.org/changeset/54645>
Comment 7 WebKit Commit Bot 2010-02-10 23:32:22 PST
All reviewed patches have been landed.  Closing bug.