return and deprecate oeb-page-head and oeb-page-foot?

[mattgarrish]

These two properties were deprecated in 3.0.1, but removed from 3.1. We never put them back as deprecated, but should we?

Or are we taking the position that CSS properties can be dropped at any time?

[dauwhe]

I would prefer we don't restore them. They were deprecated in 3.0.1, with a note saying they would be removed in a future version. Support in 3.0 was optional, and the spec even provided advice on how to use the feature given not all reading systems supported it. CSS is also clear about what happens with unknown properties.

[murata2makoto]

Have these properties been ever implemented? If not, I agree not to restore them.

[mattgarrish]

They were deprecated and not removed from 3.0.1 for the same reason all these other deprecated features were restored (i.e., to avoid any potential issues). The note about removal anticipated some other solution arriving to fill in the functionality void (a webby solution for epub 4), but there's still nothing on offer.

(And I'm not asking because I want them back, but because we're starting to play a little loose with feature removal if we drop them.)

[mattgarrish]

They could probably fit in the category of legacy features, too. Not wanted for EPUB 3, but kicking around because we brought them forward from 2.

[murata2makoto]

If we cannot safely assume that no commercial EPUB publications use these two features, I think that we should revive and deprecate them.

[dauwhe]

Will epubcheck be processing CSS files looking for things like this?

[mattgarrish]

It's not anything resembling a full-fledged css processor, but it inspects and throws warnings about position fixed and absolute.

[mattgarrish]

It's more just that the section says these are continued to be allowed, and this isn't really a major revision. I'd forgotten about them until this morning, but if we were hesitant to remove them from 3.0.1 it feels like we should stay the course and just leave them deprecated.

[GarthConboy]

I'm kinda with Dave (leave them out) -- can't say for sure nobody supports 'em, but would lean that way. We did support them in the SoftBook reading system back in the late 90's, but don't at Play Books. FWIW.

[rkwright]

FWIW, Readium has never implemented either.

[mattgarrish]

I guess what bothers me here is that removing them causes an error in the CSS, at least as far as I understand CSS. We can drop -epub- prefixed properties from the specification because it doesn't change anything as far as authoring a CSS file goes... they're still just unknown vendor extension properties to a validator whatever we do or don't say about them.

But oeb-page-head and oeb-page-foot are extensions of the display property value space. If we don't allow these, then they are errors, no? That doesn't seem in keeping with all 3.0.1 files are valid 3.2 files.

Granted, if the modernization of epubcheck brings full css validation, I expect people are going to discover all kinds of issues they never knew they had, but this would be one of our making.

It all depends on whether anyone has inserted headers/footers into publications, of course, and I have no answer to that.

[murata2makoto]

Has epubcheck report non-prefixed and non-standard properties as errors?

It all depends on whether anyone has inserted headers/footers into publications, of course, and I have no answer to that.

@GarthConboy @deborahgu and other people from the EPUB 2 era, comments?

[mattgarrish]

Has epubcheck report non-prefixed and non-standard properties as errors?

These are non-standard values on a standard property, though. That's what makes them errors in existing validators. It's a hack that takes advantage of UAs ignoring property values they don't understand, so you can add a "hiddden" display after to ensure the content doesn't get rendered. But the value itself is reported as an error by https://jigsaw.w3.org/css-validator/

If you put in any -epub- property you want, you'll only get a warning that it's an unknown vendor extension.

[GarthConboy]

Can't comment, with authority, on usage in content, unfortunately.

[mattgarrish]

Can we say that unlike the other IDPF-defined features of EPUB, these ones are inconsistent with how web technologies are extended, and given their lack of implementation we're making the decision to remove them now rather than continue to support a hack on CSS?

I can't find anywhere in the CSS specs that adding these values was ever acceptable practice? You have to have an "EPUB Profile" to rationalize stuff like this, I believe. @dauwhe?

I'd be fine with dumping these so long as we have a consistent rationale that clearly distinguishes why we're returning all the other features 3.1 dropped.

[laudrain]

@mattgarrish, I totally support:

That doesn't seem in keeping with all 3.0.1 files are valid 3.2 files.

Then as @murata2makoto I am in favor to

revive and deprecate them.

[murata2makoto]

Can we say that unlike the other IDPF-defined features of EPUB, these ones are inconsistent with how web technologies are extended, and given their lack of implementation we're making the decision to remove them now rather than continue to support a hack on CSS?

I second this argument. Breaking conformance to CSS is bad. But I propose to add a note about our rationale.

[RachelComerford]

@rdeltour @avneeshsingh is an upgrade to EPUBcheck that expands the testing on CSS significantly likely?

If it is - then I imagine removing these from the spec would create a lot of frustration for less experienced users when they see unexpected errors.

If it is not - we won't have to worry about removing them from the spec creating that problem for users.

[mattgarrish]

I don't think it's likely in the next release given that we want to get a new version out soon, but what kind of css validation epubcheck should be providing is a question we need to answer. It's a bit annoying that we don't offer any insight into potential display problems arising from poorly written css, but do we just write off improving validation because css has gone unchecked for so long? If not, this problem will manifest itself eventually in some EPUBs.

Also the claim that 3.0.1 files are valid 3.2 files is a bit disingenuous when we know that we have backwards-breaking compatibility issues that are simply hidden below incomplete validation. In going over the specs to update epubcheck, we've noticed that both this and some of the shifting/disappearing -epub- prefixed property values are technically errors now when they weren't before.

[rdeltour]

@rdeltour @avneeshsingh is an upgrade to EPUBcheck that expands the testing on CSS significantly likely?

No, it's not likely.

We will update the existing CSS rules where needed, but don't plan to improve the existing CSS parsing/validation significantly. Even if we did, we could always make a special case for these.

I second @mattgarrish's question however:

what kind of css validation epubcheck should be providing is a question we need to answer

the issue is not related to any technical limitations, it is about choosing a validation strategy, an approach we (as a community) want to define for EPUBCheck.

[avneeshsingh]

@Rachel.
Further work on CSS is not in plan for Q1 2019 EPUBCheck release. Implementing support for EPUB 3.2 is the top most priority over next 3/4 months, and further work on CSS validation will slow down the project. So, it is out of scope for Q1 of 2019.

[GarthConboy]

Surprisingly enough, I don't have a strong opinion here. On one hand, retain/deprecate is more in the spirit of our definition of 3.2, but these guys are very likely wholly unsupported, and rarely, if ever, used, and are a (clever at the time, but not now) CSS hack, so I'm okay with removing in 3.2.

[murata2makoto]

EPUB 3 has two types of extensions. The first one extends values of a standard property.

display: oeb-page-head

The second one introduces vendor properties. (e.g., -epub-text-align-last). The second one is allowed by CSS, but is the first one allowed by CSS? > @frivoal

[frivoal]

CSS deals just fine with unknown values to existing properties. That declaration gets ignored, but everything else continues to work.

I don't have enough background knowledge about this to be sure about the other reasons, but "avoiding errors in CSS" is not a valid reason to keep this around. Given that there doesn't seem to be any implementation of these features, I would suggest dropping them.

As far as what is "allowed" by CSS, there's two way to look at it:

• CSS User Agents allow you to extend anything you want in anyway you want, because they have very well defined error handling, and their behavior is very predictable in the face of incorrect/non-standard syntax

• At the time of CSS2.1 and for a while after, the CSS Working Group used to recommend using vendor prefixes for extensions, and that was ok for property names as well as for value names. However we no longer recommend that, as we have found that to be a poor solution in practice that caused a lot of problems. It is still OK to use prefixes for extensions used for example to write the UI of Firefox or iTunes, because the content and the engine are shipped together, and that CSS is never exposed to third parties, so using prefixes just avoids name collisions with existing or future open web content. But for content that is distributed separately from the UA, such as web pages which are separate from browsers, or EPUBs which are separate from readers, the CSS Working Group recommends against doing that: if nobody is going to use the feature, you did not need to release it at all, and if people are going to use it, we will be stuck with it forever despite the prefix, so we need to spend the effort in getting the name and the behavior right. So the only approach that works in the long run for things that should be broadly available to end users is to standardize them properly. The details of this policy are documented here: https://www.w3.org/TR/CSS/#responsible.

  This also argues in favor of dropping these properties and values.

To the extend they serve a useful purpose, they should be proposed to the CSS-WG.

[frivoal]

As for validating CSS in Epubcheck, I have some doubts as to how useful that is. For an error tolerant language like CSS, what really matters is what the rendering engines support.

If epubceck rejects EPUBs that contain css rules that are not allowed by the spec but understood by some reading systems, it's not really helping:

• For reading systems that understand this rule, requiring that it be removed is limiting what authors can do.
• For reading systems that don't understand this rules, because a css file with an non-understandable rule will render identically to a css file with this rule removed, so it is not making any difference

If epubcheck validates css rules that are in the spec but not understood by reading systems, then it causes no hard (since these rules will be ignored at run time), but it's also not helping.

Having epubcheck or some similar tool be connected with a database about epub readers that is similar to what caniuse.com does for browsers, and emit warnings (not errors) when you're using properties that are not supported by reading systems with large market share may be useful, to help people avoid accidentally using properties that work in their test environment but don't in the readers of used by their intended audience. But I insist these should be warnings, not errors: including rules that only work in some of the target reading systems is the normal and robust way to write css, using progressive enhancement / graceful degradation.

All in all, I think validating css for conformance is a futile exercise (and an expensive one).

[frivoal]

Breaking conformance to CSS is bad

I'd like to add details to this:

• when an individual web page or EPUB authors writes non conformant CSS, it is not bad. If they write nonsense, it will predictably and reliably be ignored by CSS engines. But what looks like nonsense to a 2015 engine might actually be a standard feature of a 2018 engine, so allowing "nonsense" is the way CSS allows authors to write new css and have predictable behavior in old engines. Forbidding that makes progress impossible

• Reading systems or specifications creating new properties or new values that are not standard CSS, and asking authors to use that is bad:

  • If nobody implements them, recommending that people use them is just a waste of time and a source of confusion.
  • If they are implemented, used, and well designed, the CSS WG can just adopt them later and make them official (but at that point changing the name will be impossible if they are already used, which is why prefixes are a bad idea), but if they are so good that the CSS-WG can just adopt them as is, then they should be standardized upfront.
  • If they are implemented, used, but not well designed, the CSS-WG may still be forced to adopt them later if there's a large amount of content using them. But people will be grumpy about adding not well designed features to a language that everybody needs to implement and that needs to be supported forever. Even if we ignore the cost on implementers (which we should not), there's a very large number of people who write css, and confusing or quirky features make the whole language harder to work with, and can waste the time of millions of people, which isn't something we should do lightly.
  • In some particularly unfortunate cases of "not well designed", it may be impossible to add to standard CSS because they conflict in some way with a feature of standard CSS. In that case, standard CSS and CSS with the proprietary extension risk being forever separate languages, and just like standard CSS cannot adopt the proprietary extension due to conflicts, the readers with the proprietary extension cannot adopt the new standard features it conflicts with.

“well designed” vs “not well designed” is not a criticism of the abilities of the people who come of with these features. It is just that CSS is a very large and very complex language, and it usual takes review by the whole community of CSS implementers and experts to make sure that the feature is designed in a way that integrates correctly with the rest.

[murata2makoto]

Florian, thank you very much for your detailed response.

What happened is bad, although I have no regrets about the introduction of vertical writing to EPUB 3 in a hurry.

But let's focus on oeb-page-head and oeb-page-foot. Your response shows that these non-standard values are as bad as (or as good as) non-standard properties. They are not particularly better or worse.

We thus have only one possible reason to drop oeb-page-head and oeb-page-foot. Although there were some implementations, we are not aware of any existing implementations. As Garth wrote, they are "very likely wholly unsupported, and rarely, if ever, used, ". Thus, I agree to drop them.

[murata2makoto]

@mattgarrish wrote

Also the claim that 3.0.1 files are valid 3.2 files is a bit disingenuous when we know that we have backwards-breaking compatibility issues that are simply hidden below incomplete validation. In going over the specs to update epubcheck, we've noticed that both this and some of the shifting/disappearing -epub- prefixed property values are technically errors now when they weren't before.

I do not agree. We drop such -epub- prefixed property values only when we are very sure that such values are almost never used. Practically, backward-compatibility is preserved. In other words, I do not think backward-compatibility is a religuous concept.

[ghost]

Agree to leave them out. Have not seen contents actually using them. Even though we would have such requirement in the future I would like to address this type of requirement (text layout/rendering) in css instead of epub spec.

[dauwhe]

Interestingly, 3.2 also removes the restriction on position:fixed. I think we are at a place where we say that EPUB is not in the business of enforcing restrictions on stylesheets. I'm considering adding a non-normative note to the changes document saying:

It is not EPUB’s role to enforce restrictions on stylesheets used in EPUB Publications. CSS has well-defined error handling, and many techniques (such as @supports and the cascade) are available to authors so that they can take advantage of newer CSS features while ensuring reasonable fallback behavior.

[mattgarrish]

I'm fine with that. In the last epubcheck meeting, we discussed putting css validation behind a switch so that you could get validation information without it polluting the default process (even if we don't get full validation in the next release, it still affects the rules we are checking).

The question was whether it should be silent by default about CSS or whether it should be something that is turned off. (For the record, I prefer the former, but it's something we need to get the CG to agree on.)

[mattgarrish]

I do not think backward-compatibility is a religuous concept.

It's not religion, but there should be consistency to what we do. Who is using bindings, for example? Triggers? There's lots of stuff that returned that we found no users or implementations for during 3.1. I think only switch had a small user base that we'd actually upset by dropping.

While I wouldn't hold this release up over it now, perhaps 3.1 was fine in most ways beyond the version number change.

[dauwhe]

We seem to have consensus on removing oeb-page-*. I've added a section about that to the changes doc, and included the note I mentioned earlier.

I think we have some sort of consensus that EPUB is not in the business of validating CSS. But there is a question of whether EPUBCheck should optionally report on things that are likely to be problematic. Would it be appropriate to (optionally?) provide info that position:fixed is used, or the direction property? And how would these things be expressed in the spec so that it would be appropriate for EPUBCheck to have an opinion?

[rdeltour]

Note: I just created a new issue (w3c/publ-cg#69) to discuss EPUBCheck's behavior wrt CSS validation.

[murata2makoto]

It's not religion, but there should be consistency to what we do. Who is using bindings, for example? Triggers? There's lots of stuff that returned that we found no users or implementations for during 3.1. I think only switch had a small user base that we'd actually upset by dropping.

Triggers were not supported for a while but are supported by Edge. Something similar might happen to other mechanisms. But oeb-page-* dates back to the EPUB2 era. We can safely assume that there are no submarine implementations.

[dauwhe]

Closing as we've made the necessary edits to the changes doc.