deprecated the rendition:orientation property #2831
Conversation
iherman
added
Spec-EPUB3
|
The resolution says "update Reading Systems to ignore it." I am not sure what to do here: the RS spec simply refers to the authoring spec for all deprecated features, without listing them or telling them what to do if those features are met. I see no reason for this property to be an outlier in this respect... @mattgarrish ? |
Unfortunately, I don't think it's that easy. To date, we've deprecated stuff without saying that reading systems have to stop supporting it. We've left it to developers to decide if it's worth the effort, and have kept the processing sections for font obfuscation and epub prefixed css properties, for example, though these also refer to back to the rs 3.3 specification for details. This change is contradictory if we're saying that reading systems must stop supporting rendition:flow. We can't say that they may support deprecated features and also that they must not support this one. We might be able to work around it using SHOULDs, but then we'd still need to keep the processing section and also have it point back to 3.3. For example:
If it's only a SHOULD to ignore the property, then the MAY support statement isn't so problematic. But if we're requiring all reading systems to ignore the property and use their own default going forward, then we'd have to look at changing the appendix wording to something like:
That would give more wiggle room to say in the rendition:flow section that they must not support the property and overrides anymore. But it still means retaining the section; I don't think we can get around that. Do you know how strictly we want to stop support? |
|
Heh, I just noticed I was responding to the wrong property. Not sure where I thought I saw rendition:flow being removed... But I think the issue remains the same. We have processing instructions for rendition:orientation that we have to do something about if reading systems can continue to support the property. If the only instruction is that rendition:orientation can be supported as in the authoring spec, then the requirements on the rs get lost (even if they're pretty simplistic in this case). |
|
Thinking out loud now, but a third option might be to list the deprecated reading system features first and include rendition:orientation in it. And then follow that by saying that reading systems may support deprecated authoring features except where their processing is also deprecated... ? |
|
Answering your question:
There was a brief discussion to say that the RS should always behave as if the property was set to "auto". Which, I believe, essentially says "ignore the property and decide it for yourself" based, e.g., on the physical orientation of the device. But that is, I believe, obvious, so not sure how to put it as a requirement, so, during the discussion, the WG just said to drop it. It feels to me as if this was the general approach towards all deprecated features, so maybe we can say, in that section, that RS should ignore those properties and, where applicable, behave according to what an "auto" value defines. After all, "auto" is present in many of these properties, it is not special to |
Ya, "auto" was created specifically so that all reading systems were compliant even if they didn't support fxl. It's basically a default to do whatever you do. The problem is you can't mention to default to auto without the old context. But maybe it's okay to just take the section out and list it as deprecated in the RS appendix without any other changes. We say that reading systems may support deprecated features but assuming some developer really wants to support this property for some reason, when they come back to the RS specification they're going to find that the processing behaviours are also deprecated. If they still want to go ahead with support, they can follow the reference back to the 3.3 definition. It was having it listed as deprecated in the authoring spec but made to disappear from the rs that struck me as odd. (Feel free to change "reading" to "Reading" in the first paragraph of the appendix, and also move that appendix after the RSO appendix to match the reorg we did in the authoring spec.) |
ack. Done. |
iherman
left a comment
iherman
left a comment
There was a problem hiding this comment.
It was having it listed as deprecated in the authoring spec but made to disappear from the rs that struck me as odd.
Maybe, before publishing, we can decide to make an explicit list; we shall see. If we do it now, we will probably forget some...
Not sure what you mean here. There already are deprecated processing aspects listed. It's not just a referral across to the authoring specification. If we're going to remove the whole section and take the "it never existed" approach rather than deprecate, the minimum we need to do is log that support for the property is gone. It's a significant change from 3.3. |
What I meant is that, in the current form, the text says:
and other, similar cases will come; at some point we may want to make an explicit listing of "orientation overrides properties". But, thinking it again, I believe it is all right as it is.
I believe the "never existed" approach is not an alternative due to the backward compatibility requirement. |
|
In view of the decision taken at the F2F a number of properties will have the same fate as the orientation property. We have also agreed that (1) @HadrienGardeur will make a complete listing of which properties should be deprecated and (2) we would extend the current PR to include those, rather than having separate PR-s. Ie, at this moment, the PR should not be merged. I will mark it as "draft" to avoid accidental GitHub actions... |
This implements the F2F Resolution on 10th of November. In particular:
See:
Preview | Diff