Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Interop] Prefixed properties #32

Closed
JayPanoz opened this issue Feb 21, 2018 · 12 comments
Closed

[Interop] Prefixed properties #32

JayPanoz opened this issue Feb 21, 2018 · 12 comments

Comments

@JayPanoz
Copy link
Collaborator

So we already have this issue in practice, cf. vertical-writing (issue #19), for which authors’ stylesheets are missing the necessary prefixed properties for some styles (-ms-, -moz-, etc.) and contents won’t render as expected.

Have just received this piece of information from @SeldomScene:

Hi Jiminy,

Just for your info, be careful with prefixed properties, as Google asked us to remove every prefixed properties except those used by them (i.e. -webkit-), because their programs didn't ingest correctly our files (it's new).

So we have to remove any -ms- and -moz- existing in our files...

Vincent

EUB3 ISIcrunch platform for education

I’ll repeat what I said in issue #26.

If that’s Google Play Books, they’re consequently creating an interoperability issue – and we already have an awful lot because vendors decide to do such stuff unilaterally. It also breaks yet another fundamental rule of CSS, and change the way it is working so this is bad. This should be raised at a higher level, because it impacts the whole ecosystem and, more importantly, competitors.

How are they parsing CSS in the first place? You can’t encounter this issue unless you create it and are extremely lazy – in the worst case scenario, stripping those declarations is a 2-line script…


There is a bunch of styles for which you absolutely need the prefix, and not having all whenever needed will have consequences and create rendering issues.

So if we have Reading System vendors telling authors to not use them because they have a bug, it hurts the whole ecosystem.

More generally, what do we want to do about this? Put the burden on authors or make up for the missing properties, when applicable?

That will impact Trident (IE11), EdgeHTML (MS Edge), and Gecko/Quantum (Firefox). It doesn’t impact the apps, which are using Blink/Webkit.

@llemeurfr
Copy link
Contributor

llemeurfr commented Feb 21, 2018

I think we have to use the W3C EPUB 3 CG and DPUB BG as forums for discussing such issues. In this very case, we have a chance, as Garth can be put easily in the loop.

@JayPanoz
Copy link
Collaborator Author

Yeah was thinking about raising a global interop issue in the mailing list, as we encountered quite a lot of issues related to this, and even took decisions based on what other Reading Systems do.

The thing is, at the higher level, it can very quickly turn into a WHATWG-style Interest Group as it’s a global issue Reading Systems have to tackle voluntarily – that’s to say “take the spec as a reference, check where RS differ, agree how it should be managed, update/report to spec editors.”

@llemeurfr
Copy link
Contributor

Not the mailing list, but a Github issue I'd say; I can open it. The EPUB 3 CG could become a good place for such WHATWG-style discussions (better than crating a new working group elsewhere IMO).

@JayPanoz
Copy link
Collaborator Author

Oh yeah no, was not saying “let’s create another group”, but in practice, yeah, you have a “subgroup in the group” cf. browser vendors in the CSSWG, regularly making new proposals and following-up on issues they encountered trying to implement a module.

@GarthConboy
Copy link

GarthConboy commented Feb 21, 2018

I would be interested in seeing the actual feedback from Play Books -- there should be no problem with other CSS prefixes in content ingested into our platform.

@SeldomScene can you please track down the original communication from Play Books? If there is an issue, it would seem it should be a bug! :-)

@JayPanoz
Copy link
Collaborator Author

Thanks, appreciated.

@JayPanoz
Copy link
Collaborator Author

Ok, so discussed this issue with @SeldomScene over the phone and got further details. cc @GarthConboy

This issue impacts complex fixed-layout contents with a lot of pages (educational publications) and is indeed very recent.

It seems removing unnecessary prefixed properties (CSS, inline styles) is a quick fix, which was indeed advised, because long books (e.g. 250–300-pages) were suddenly rejected as parsing failed – it worked A-OK before but we no additional info was given so we’re all at sea.

This reminds me of another issue in another repo posted back in 2014. I’m not saying they are related, obviously, but it is at least noteworthy because of the characteristics (long FXL ebooks).

@GarthConboy
Copy link

GarthConboy commented Feb 22, 2018

Thanks @JayPanoz

I suspect the removal of "other prefixed" CSS properties somehow incidentally resolved the ingest issue (assuming the content was being rejected by the Publisher Portal for Google Play Books), as there is no inherent issue with said properties. If I could get a sample of a failing title, I'd be happy to take a look.

I would kinda hope, for all RS's performance, that a long FL title has a CSS file per page, rather than one huge one for the entire book= -- FWIW.

@JayPanoz
Copy link
Collaborator Author

Ok thanks. This is the conclusion I could draw as well.

@SeldomScene and @GarthConboy, would it be possible to manage this issue in private as it clearly is not related to ReadiumCSS and I’ll probably not add it to our EPUB Compat doc for the time being since it’s incidental? Thanks!

@JayPanoz
Copy link
Collaborator Author

Also, @llemeurfr I know you have a lot of work and really don’t want to add a lot to your TODO list but can you serve as a liaison to ease the process if needed?

If not, I can assign myself but I think this exchange could serve other EDRLab’s members, especially the ones building authoring tools, as well…

@llemeurfr
Copy link
Contributor

ok, let's close this thread and finalize privately.

@GarthConboy
Copy link

Deal! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants