-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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. |
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.” |
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). |
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. |
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! :-) |
Thanks, appreciated. |
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). |
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. |
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! |
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… |
ok, let's close this thread and finalize privately. |
Deal! :-) |
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:
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.
The text was updated successfully, but these errors were encountered: