Bug #84513 for CSS-Inliner: die'ing because of linked stylesheets

Mon Apr 08 21:19:36 2013 me [...] justinsimoni.com - Ticket created

Subject:

die'ing because of linked stylesheets

Is there a good reason that this module is designed to die(), if you feed it a string, with a linked stylesheet? If anything, wouldn't it be best to simply warn() about that, or even better, deal with it, transparently if there's a base url, ala: my $inliner = CSS::Inliner->new(); $inliner->read( { html => $s, base_url => 'http://example.com', } );

Tue Jul 23 16:59:59 2013 KAMELKEV [...] cpan.org - Correspondence added

Hi, Inliner works best for atomic documents, as the workflow is substantially simpler. For example if you provide a document that includes a single stylesheet within the html itself (rather than linked) you're going through an unambiguous set of behavior. This is actually what it was designed for from the ground up. Specifically it was designed to facilitate inlining styles for use with email. In these cases you almost always have all the assets within a single document. There are quite a few people using the tool for this explicit purpose, and to that end it works rather well. For remote documents things get dicier because behavior becomes ambiguous. Should it die, or provide a warning, or keep going as if nothings wrong? There is no clear answer on what's best for everyone. Your point below is well taken, and I'd suggest writing a patch to make it behave in such a way, and we'll see if that ends up being viable or breaks existing implementations in the wild. I think probably we could make it work in a way whereby it afforded itself to more people while die'ing less. In such a case, then yeah, this is a good idea. -Kevin On Mon Apr 08 21:19:36 2013, JJSIMONI wrote: Show quoted text

> Is there a good reason that this module is designed to die(), if you > feed it a string, with a linked stylesheet? If anything, wouldn't > it be best to simply warn() about that, or even better, deal with > it, transparently if there's a base url, ala: > > my $inliner = CSS::Inliner->new(); > $inliner->read( > { > html => $s, > base_url => 'http://example.com', > } > ); > >

Tue Jul 23 16:59:59 2013 The RT System itself - Status changed from 'new' to 'open'

Mon Sep 16 11:01:19 2013 wonko [...] cpan.org - Correspondence added

On Tue Jul 23 16:59:59 2013, KAMELKEV wrote: Show quoted text

> Hi, > > Inliner works best for atomic documents, as the workflow is > substantially simpler. For example if you provide a document that > includes a single stylesheet within the html itself (rather than > linked) you're going through an unambiguous set of behavior.

While I agree with the sentiment of this, in practice it can cause real problems. For instance, I have an email which uses a <link> to external google font API to provide a special font for the mailing. If the email is read offline it's no big deal because the CSS will fall back to a different font. And the styles in that style sheet don't need to be inlined because it's basically just defining a font, not doing anything with the elements of my document. But CSS::Inliner will die when it can just ignore it and everything would work just fine.

Tue Oct 01 18:10:54 2013 KAMELKEV [...] cpan.org - Correspondence added

Hi Michael, Ideas for implementation? To take a baseref as he suggests is not exactly hard, but does that actually solve problems for you? I've never run into this particular circumstance myself. I have spent an inordinate amount of time working towards UTF8 support as of late, so the ambiguity here makes it less obvious on how to prioritize that work. -Kevin On Mon Sep 16 11:01:19 2013, WONKO wrote: Show quoted text

> On Tue Jul 23 16:59:59 2013, KAMELKEV wrote:

> > Hi, > > > > Inliner works best for atomic documents, as the workflow is > > substantially simpler. For example if you provide a document that > > includes a single stylesheet within the html itself (rather than > > linked) you're going through an unambiguous set of behavior.

> > While I agree with the sentiment of this, in practice it can cause > real problems. For instance, I have an email which uses a <link> to > external google font API to provide a special font for the mailing. If > the email is read offline it's no big deal because the CSS will fall > back to a different font. > > And the styles in that style sheet don't need to be inlined because > it's basically just defining a font, not doing anything with the > elements of my document. > > But CSS::Inliner will die when it can just ignore it and everything > would work just fine.

Mon Dec 02 22:12:05 2013 KAMELKEV [...] cpan.org - Correspondence added

New release posted. We no longer die under this particular circumstance. The new version supports a relaxed mode which is way more relaxed than the standards mode. Additionally standards mode does not die when it encounters such link tags, but instead will now produce a warning. This probably will get you further. Moving forward (and I'll leave this ticket open) we want to report a warning every single time we find a non-expandable stylesheet. If we find an expandable (fully qualified reference) then we will attempt to expand it even though the document was not fetched. I'm not super excited about passing a "baseref" argument, as I have zero use for this myself. If you can write a comprehensive patch and tests then we can look into what is involved in merging that in. On Mon Apr 08 21:19:36 2013, JJSIMONI wrote: Show quoted text

> Is there a good reason that this module is designed to die(), if you > feed it a string, with a linked stylesheet? If anything, wouldn't it > be best to simply warn() about that, or even better, deal with it, > transparently if there's a base url, ala: > > my $inliner = CSS::Inliner->new(); > $inliner->read( > { > html => $s, > base_url => 'http://example.com', > } > );