Out of scope?

[frivoal]

The various things listed in the wiki here https://github.com/w3c/publ-cg/wiki/Rendering#rendering don't seem to quite fit the scope of the CG, which is, as far as I understand the charter, about maintenance of EPUB3 and related things, not about new features.

Regardless of the charter, Image Bleeds (including page floats and the actual bleed), footnotes, and Marginalia are absolutely in scope for the CSS WG, and already have partial answers there.

https://drafts.csswg.org/css-page-floats/ https://drafts.csswg.org/css-page/#bleed https://drafts.csswg.org/css-gcpm/#creating-footnotes

I strongly encourage members of EPUB CG to work on these topics, but not in isolation, and to join the CSS WG to contribute to the development there. Ending up with two partial answers to these questions, one in EPUB and one in CSS, would be a very bad outcome.

[dauwhe]

This sort of thing is of interest to the community, and I think there's lots of precedent in the W3C for community groups to incubate ideas that may later move to the appropriate working group. I think this CG has the right participants for early exploration of such ideas.

In some sense, what we're talking about is an extension of the idea of mixing fixed-layout with reflowable layout, which is already allowed in EPUB 3.0.1, but not widely implemented. I do think that this, given it's a modest adjustment to existing capabilities of EPUB 3, is in scope for the CG to explore, although not to specify.

It's also possible that some solutions to these problems may be out of scope for CSS, as they may be more related to the user interfaces of reading systems than to web rendering. We're at such an early stage we just don't know yet.

[artbyrt]

Another issue which might be discussed is ability to mix single page and spreads in fixed layout. Currently, the standard places an either/or global meta property on the “rendition:spread” which means ‘letterboxing’ the single pages to accommodate the spread/s or eliminating spread altogether.

<((:-) …LOL…. (-:))>

The possible's slow fuse is lit by the Imagination. –Emily Dickinson

ruth tait http://www.artbyrt.com O: 416 900 5631

On Jun 6, 2017, at 10:15 AM, Dave Cramer notifications@github.com wrote:

This sort of thing is of interest to the community, and I think there's lots of precedent in the W3C for community groups to incubate ideas that may later move to the appropriate working group. I think this CG has the right participants for early exploration of such ideas.

In some sense, what we're talking about is an extension of the idea of mixing fixed-layout with reflowable layout, which is already allowed in EPUB 3.0.1, but not widely implemented. I do think that this, given it's a modest adjustment to existing capabilities of EPUB 3, is in scope for the CG to explore, although not to specify.

It's also possible that some solutions to these problems may be out of scope for CSS, as they may be more related to the user interfaces of reading systems than to web rendering. We're at such an early stage we just don't know yet.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-cg/issues/11#issuecomment-306499498, or mute the thread https://github.com/notifications/unsubscribe-auth/AMwGgJIjAJfVD6xgrGcRzXNkd1Yy1PKYks5sBV8EgaJpZM4NxY2o.

[frivoal]

This sort of thing is of interest to the community

Sure, but the community in the broad sense is not the same thing as a community group chartered to do a specific thing. My reading of the CG charter doesn't make it look like developing new layout features for paginated documents is what this group is supposed to be about, so there's a good chance that people who care about that haven't all joined here.

I think there's lots of precedent in the W3C for community groups to incubate ideas that may later move to the appropriate working group.

Right. For things that might fall under the scope of the CSSWG but aren't being developped there, starting iterating on an idea elsewhere is certainly fine. For things that currently have a proposal in the CSSWG, I don't think it is a great idea for a CG to independently declare that they are of not interest to the CSSWG and that it ought to work on its own EPUB specific solution.

For instance, here's a quote form https://github.com/w3c/publ-cg/wiki/Rendering#rendering

But the "bleed" aspect isn't necessarily a good fit for CSS, given that this isn't an issue for the larger web platform.

bleed has a proposal in CSS, as we've agreed that printing was relevant for the larger web platform, and bleed is a relevant issue for printing. Exploring the shortcomings of the current solution or alternative designs is a worthy exercise. Doing an epub specific design from scratch and asuming others are not interested seems less productive.

[murata2makoto]

In the past, IDPF has done some CSS extensions. For example, display: oeb-page-head and display: oeb-page-foot. In my understanding, all such extensions have miserably failed. I thus think that the CG should never try to create a variation of CSS for publishing.

On the other hand, I would like the CSS WG to pay more attention to publishing requirements. I thus think that the CG should provide a detailed prioritized requirement list and request the CSS WG to address them. Paged media should be top in the list.

[rickj]

This sort of thing is of interest to the community Sure, but the community in the broad sense is not the same thing as a community group chartered to do a specific thing. My reading of the CG charter doesn't make it look like developing new layout features for paginated documents is what this group is supposed to be about, so there's a good chance that people who care about that haven't all joined here.

My take on this: The Business Group Steering Committee has been hearing a lot in the marketplace about this (and other) needs. Per their charters, they asked the CG to do some incubating, including (were appropriate, and when the timing is right) with other W3C groups.

IMO the CG needs to incubate on the use cases, approaches, and other thoughts, and absolutely coordinate with others, such as CSS, at the right time.... with @frivoal 's support, perhaps that time is earlier, and not later?

[frivoal]

with @frivoal 's support, perhaps that time is earlier, and not later?

I think so, absolutely.

For things that have no solution anywhere yet, incubating the idea somewhere is a good idea. For things that do have solutions (or even partial ones) in established groups, I would strongly encourage not incubating new ideas in a separate forum as a first move. If the requirements of the publishing community are not clear, working on that first is fair. But once the requirements are clear, evaluating the existing specifications and sending feedback to the working groups working on them seems much more productive than starting a competing proposal.

Solutions to bleed, footnotes, and page floats are being specified by the CSSWG. Maybe they are good, maybe they are not. Feedback and iteration on that would be much more useful to the web platform than having to support -epub-bleed and bleed separately

Per their charters, they asked the CG to do some incubating

I'm confused: neither the BG nor the CG's charters even mention incubation.

The key phrase in the CG scope is "revisions to, and maintenance of, EPUB 3 and extension modules". This seems pretty far off from "incubate new layout features".

As for the BG charter, what I understand is that it is supposed to channel communication between the publishing community and the broader web community, not instruct publishing-specific CG/WGs to do publishing specific work.

There's a WG chartered to work on layout (the CSSWG). There's a CG for Print and Page Layout. This CG is chartered to work on EPUB maintenance. Yes, people who work on EPUB tend to have an interest in layout for paged media as well, but they are not alone being interested in that topic, and working on solutions in isolation of everyone else who is interested does not seem desirable.

---

Don't get me wrong, I am not trying to block progress on these features, very much the opposite. Bleed, page floats, and footnotes are things I care about, and that my company (Vivilostyle) has implemented and is looking forward to improve upon.

I would find it terrible if the solutions to these problems in the CSSWG failed due to a lack of critical mass working on them, while different solutions to the same problems developed in a publishing-only forum also failed due a lack of involvement from the web platform experts.

[therealglazou]

While I'm all in favor of new features, the Charter "seems" to make a very distinction between existing features or even work coming from IDPF and new stuff that "should" fall into the EPUB4 basket and then the WG ; or even other W3C WGs like the CSS WG... Sorry but the CG must not step on chartered activities in existing WGs.

[BillKasdorf]

+1 to both points.

Bill Kasdorf

VP and Principal Consultant | Apex CoVantage

p:

734-904-6252 m: 734-904-6252

ISNI: http://isni.org/isni/0000000116490786 ORCiD: https://orcid.org/0000-0001-7002-4786https://orcid.org/0000-0001-7002-4786?lang=en

From: MURATA Makoto [mailto:notifications@github.com] Sent: Tuesday, June 06, 2017 6:01 PM To: w3c/publ-cg Cc: Subscribed Subject: Re: [w3c/publ-cg] Out of scope? (#11)

In the past, IDPF has done some CSS extensions. For example, display: oeb-page-head and display: oeb-page-foot. In my understanding, all such extensions have been miserably failed. I thus think that the CG should never try to create a variation of CSS for publishing.

On the other, I would like the CSS WG to pay more attention to publishing requirements. I thus think that the CG should provide a detailed prioritized requirement lists and request the CSS WG to address them. Paged media should be top in the list.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/w3c/publ-cg/issues/11#issuecomment-306630149, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIYxNWhlDEAvRgnAyVx_mHAFUaByy1wXks5sBcwlgaJpZM4NxY2o.

[TzviyaSiegman]

@therealglazou and @frivoal I think this might be the wrong place to discuss this issue. This has become a discussion about the charter, not technical scope. Can I recommend that we take this to the BG email list (W3C Publishing Business Group public-publishingbg@w3.org)? I recommend closing the issue, but I leave that to @dauwhe and @RachelComerford

[therealglazou]

@TzviyaSiegman , excuse me but why the BG ? This is about (on one hand) the CG and its chartered scope and (on the other) relationships between the CG and other WGs ; so I would like to understand why the BG should be involved.

[TzviyaSiegman]

BG works on relationship management for all of Publishing@W3C. Current status "it's complicated." Point is that this is not a GH issue. Bring it to one of the email lists.

[mattgarrish]

Where specifically does the charter say new features are out of scope?

As noted above, it says: "The EPUB 3 CG shall develop future revisions to, and maintenance of". It does not say that only maintenance is in scope, or that revisions are only for maintenance. All it says is that a major revision is out of scope, which I completely agree with. New features don't always necessitate a major revision depending on their nature.

I'm not out to argue that the features that started this thread should be developed uniquely for 3.1, but the mission says that the CG is for "ongoing technical development of EPUB 3", and in the scope that "follow-on work from EPUB 3.1" is the purpose of the group. Follow-on is continuation, not feature freeze.

It also says in the scope: "Coordination with the publishing industry regarding requirements and priorities for ongoing EPUB 3 development will be delegated to the W3C Publishing Business Group (BG)." Again, the BG asking the CG for action on specific feature needs is again perfectly in line with the charter. Why would the BG waste time finding priorities for ongoing development if development is frozen?

The primary missing piece I see is that the CG is also supposed to coordinate with the EPUB 4 WG: "The EPUB 3 CG will coordinate its work with such new WG, and meanwhile with the existing W3C Digital Publishing Interest Group (DPUB IG)". I believe this is critical, as the CG should not introduce features at this point that won't have a corollary in EPUB 4, even if the implementations are by necessity different (although ideally not).

I also don't see why incubation of ideas is out of scope. Again, not trying to strike up a debate about whether that means incubating ideas that may belong in other groups, but to do meaningful revisions some pre-standardization work sounds like a sane enough idea.

Sorry for the long response, but I'm just not following the thread of thought that says we're in a feature freeze.

[dauwhe]

excuse me but why the BG

From the CG Charter:

This charter may be amended at any time by consensus, or lacking consensus a simple majority vote, of EPUB 3 CG participants subject to the approval of the W3C Publishing BG.

Big picture: People have expressed interest in various new features, closely related to EPUB 3 as it exists today. I find it entirely reasonable to have preliminary conversations about such features here, precisely to determine:

1. If they are viable features, both technically possible and with community support
2. If they relate to other parts of the web platform, and if so, what parts?
3. If they would be better pursued by other groups, which may be the Publishing Business Group, CSSWG, other community groups, etc.
4. If this CG can provide input, use case, or examples to other groups.

The bleed discussion may go nowhere. It may end up in CSSWG. It may become fodder for a web platform group. It may end up being an extension to FXL metadata in EPUB 3.1415926. We just don't know enough to make any of these determinations right now. Which is why having a conversation here makes sense. But I promise we won't develop EPUB-only CSS specs here.

[BillKasdorf]

+1, especially to “But I promise we won't develop EPUB-only CSS specs here.”

Bill Kasdorf

VP and Principal Consultant | Apex CoVantage

p:

734-904-6252 m: 734-904-6252

ISNI: http://isni.org/isni/0000000116490786 ORCiD: https://orcid.org/0000-0001-7002-4786https://orcid.org/0000-0001-7002-4786?lang=en

From: Dave Cramer [mailto:notifications@github.com] Sent: Wednesday, June 07, 2017 11:20 AM To: w3c/publ-cg Cc: Bill Kasdorf; Comment Subject: Re: [w3c/publ-cg] Out of scope? (#11)

excuse me but why the BG

From the CG Charter:

This charter may be amended at any time by consensus, or lacking consensus a simple majority vote, of EPUB 3 CG participants subject to the approval of the W3C Publishing BG.

Big picture: People have expressed interest in various new features, closely related to EPUB 3 as it exists today. I find it entirely reasonable to have preliminary conversations about such features here, precisely to determine:

1. If they are viable features, both technically possible and with community support
2. If they relate to other parts of the web platform, and if so, what parts?
3. If they would be better pursued by other groups, which may be the Publishing Business Group, CSSWG, other community groups, etc.
4. If this CG can provide input, use case, or examples to other groups.

The bleed discussion may go nowhere. It may end up in CSSWG. It may become fodder for a web platform group. It may end up being an extension to FXL metadata in EPUB 3.1415926. We just don't know enough to make any of these determinations right now. Which is why having a conversation here makes sense. But I promise we won't develop EPUB-only CSS specs here.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/w3c/publ-cg/issues/11#issuecomment-306828550, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIYxNX6D3ez_YTiaUZa7NdTVruC8IMaeks5sBr-7gaJpZM4NxY2o.

[murata2makoto]

It may end up being an extension to FXL metadata in EPUB 3.1415926.

EPUB already has too many rendering metadata. They do what CSS cannot do. Some (e.g, rendition:align-x-center) have not been widely implemented. Others (FXL) have been widely implemented and used..

If the unification of publishing and web is our goal, we should study whether each rendering metadata should be generalized to the OWP. I oppose to the introduction of more rendering metadata.