Out of scope? about publ-cg HOT 15 CLOSED

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.

from publ-cg.

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.

from publ-cg.

from publ-cg.

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.

from publ-cg.

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?

from publ-cg.

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.

from publ-cg.

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.

from publ-cg.

from publ-cg.

@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 [email protected])? I recommend closing the issue, but I leave that to @dauwhe and @RachelComerford

from publ-cg.

@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.

from publ-cg.

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.

from publ-cg.

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.

from publ-cg.

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.

from publ-cg.

from publ-cg.

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.

from publ-cg.