You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"MUST ignore proprietary metadata properties" at the end of 3.3 in EPUB-RS 3.3 #2134
Third, I have never understood what this sentence means
Apple used to define orientation-lock properties for fixed layouts, for example. I don't know that these conflicted with rendition:orientation, but what would you call this metadata if not proprietary? 3rd party? Vendor-specific?
The restriction, though, would be better placed on not making proprietary metadata extensions that conflict with the behaviours, as if you make something like that why would you turn around and ignore it? I don't believe we were trying to ban fxl extensions as much as not fragment standardized behaviours.
In other words, I'd move the section under FXL and make it more like:
Extension Properties
Reading System developers MAY introduce additional properties to control the rendering of Fixed Layout Documents provided the expressions do not use the rendition: prefix and do not conflict behaviorally with those defined in this section.
And then add some boilerplate about how standardizing within W3C is preferred to ensure interop.
One of the core tasks of the coming months will be to complete the test suite. It is a tedious work of adding tests to all statements, and any help will be necessary...
Apple used to define orientation-lock properties for fixed layouts, for example. I don't know that these conflicted with rendition:orientation, but what would you call this metadata if not proprietary? 3rd party? Vendor-specific?
I was wondering if this statement is to warn Apple but I was not sure.
This requirement was useful at that time, but do we still need it? Your rewrite implicitly recommends proprietary extensions.
This requirement was useful at that time, but do we still need it?
Ya, I don't know how likely it is we'll see more now that the metadata is established, but to me there's no harm in telling people they can't use the rendition prefix space or conflict with the existing properties. Better to be clear than say nothing. Otherwise, someone could create their own rendition:* property and it would be perfectly valid.
Your rewrite implicitly recommends proprietary extensions.
I wouldn't say it recommends any more than our allowing custom attributes encourages that practice, but that's also why I suggested we should say the usual things about standardizing within W3C rather than coming up with your own.
We could also make this section parallel the custom attributes section to better harmonize the two. It states the attributes are for experimentation, for example, which is typically considered okay.
Activity
mattgarrish commentedon Mar 27, 2022
Apple used to define orientation-lock properties for fixed layouts, for example. I don't know that these conflicted with rendition:orientation, but what would you call this metadata if not proprietary? 3rd party? Vendor-specific?
The restriction, though, would be better placed on not making proprietary metadata extensions that conflict with the behaviours, as if you make something like that why would you turn around and ignore it? I don't believe we were trying to ban fxl extensions as much as not fragment standardized behaviours.
In other words, I'd move the section under FXL and make it more like:
And then add some boilerplate about how standardizing within W3C is preferred to ensure interop.
iherman commentedon Mar 28, 2022
@murata2makoto on the question of missing tests, see my comment at #2132 (comment).
One of the core tasks of the coming months will be to complete the test suite. It is a tedious work of adding tests to all statements, and any help will be necessary...
cc @dlazin
murata2makoto commentedon Mar 28, 2022
@mattgarrish
I was wondering if this statement is to warn Apple but I was not sure.
This requirement was useful at that time, but do we still need it? Your rewrite implicitly recommends proprietary extensions.
mattgarrish commentedon Mar 28, 2022
Ya, I don't know how likely it is we'll see more now that the metadata is established, but to me there's no harm in telling people they can't use the rendition prefix space or conflict with the existing properties. Better to be clear than say nothing. Otherwise, someone could create their own rendition:* property and it would be perfectly valid.
I wouldn't say it recommends any more than our allowing custom attributes encourages that practice, but that's also why I suggested we should say the usual things about standardizing within W3C rather than coming up with your own.
mattgarrish commentedon Mar 28, 2022
We could also make this section parallel the custom attributes section to better harmonize the two. It states the attributes are for experimentation, for example, which is typically considered okay.
iherman commentedon Mar 28, 2022
Isn't pr #2138 meant to fix this issue? If so, we should mark it as such...
mattgarrish commentedon Mar 28, 2022
Yes, went off to hunt down the RS diff/preview links to paste in and forgot to add a "fixes" statement. Done now.