W3C home > Mailing lists > Public > www-style@w3.org > November 2011

[CSSWG] Minutes and Resolutions TPAC 2011-11-01 Tuesday Morning I: CSSOM, IDPF

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 28 Nov 2011 13:41:43 -0800
Message-ID: <4ED40017.9010505@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*


   Discussed how to make progress on CSSOM spec.
   RESOLVED: add a notice to the top DOM L2 Style indicating portions of the
             spec are obsolete linking to Bert's email and linking to CSSOM.
             Also, the specific obsolete section of DOM L2 Style must be marked
             as such

IDPF-CSSWG Joint Meeting

   IDPF and CSS discussed their very different goals and approaches to
   standardization and how to coordinate.

====== Full minutes below ======


Scribe: sylvaing

   <fantasai> http://dev.w3.org/csswg/cssom/
   annevk: the CSSOM is a collection of various CSS features exposed through
   annevk: such as alternate stylesheets, stylesheets themselves
   annevk: and a new part is CSS values which is very new
   annevk: we are now waiting for implementation experience for CSS values
   florian: we had talked about defining serialization
   annevk: nothing new at this point
   fantasai,annevk: we had talked about defining the serialization of basic
                    types in a Serialization module
   fantasai: most of them were in CSS2.1 or should be new units in css3-values
             and Color
   jdaggett: there may a problem with the way we've modularized; some modules
             need to rev often than others. CSSOM is one of those
   Tab: some specs need to be "living" ?
   fantasai: that was the case for many modules. hence the modularization
   jdaggett: if I add an at-rule I need a DOM interface so I'm adding things
             that should be in the OM
   annevk: if you add an at-rule you should define all the related OM pieces
           in the same place
   fantasai: the problem we have right now is bootstrapping. we don't have a
             2.1 for serialization
   fantasai: until we have that we will be discussing process
   glazou: we're also going to talk about the OM forever until we fix its
           issues and implement the fixes
   glazou: we need a better OM
   tantek: I agree we need a foundational OM spec.
   tantek: just like HTML went through a painful process of defining an OM
           in sync with content out there. Starting with a known feature set
           would be easier and establish a baseline
   tantek: Instead of redrawing module lines, we should start by creating an
           OM for CSS 2.1
   <fantasai> +1
   jdaggett: we do not have a consistently defined DOM interface. some modules
             define new at-rules but implementations may be using different
             rule constants which should be coordinated across specs
   jdaggett: there is no one looking at these features from an OM perspective.
             It's up to each editor and each editor's level of OM experience
             e.g. some modules will not define exceptions correctly
   jdaggett: so specs are inconsistent
   tantek: I suggest the common reference baseline would be a 2.1 OM
   jdaggett: how does that help with new features
   fantasai: like non OM features, most new OM features derive from existing
             features in 2.1 and you would have patterns to base new interfaces
   jdaggett: the pattern for what you have to do to specify a new at-rule is
             not defined; I'm not sure a 2.1 OM defines it. how is that
             different from what we have now ?
   jdaggett: I think we need more: at least a set of how-to guidelines e.g.
             if you define a new at-rule, these are the things you need to
   tantek: we agree on goals, we're only discussing how to get there
   jdaggett: I don't think we even have consensus on issues such as prefixed
             at-rules and how this relates to at-rule constants
   glazou: this should definitely be specified
   tantek: we should reach a bar where each module should define its DOM
   <fantasai> Proposal: Modularize CSSOM. Break it up into a a Serialization
              module, a Values module, an At-Rules module, a Media Queries
              module, etc.
   tantek: keeping things separately did not help HTML
   dbaron: there are modules how define their own OM e.g. Transitions (events),
           Animations (OM), Fonts, Conditional....
   dbaron,annevk: Transforms has a value type but we agreed to deprecate the
                  CSSValue type it uses
   tantek: I think we need something that is up to date with 2.1
   dbaron: part of the base problem is that DOM L2 Style has a number of
           features that are wrong, and a number of things we agreed to
           change but never fixed
   dbaron: we need to define this core baseline so we can build on top of it

   annevk: as far as values, we deprecated the 2003 model but never replaced it
   annevk: I didn't want to spec out the new model fully until we at least
           had some implementation experience with it
   tankek: is there interop among browsers for 2.1 CSSOM ?
   dbaron: what do you mean by 2.1 ?
   tantek: what is in Gecko, Webkit, Trident today ?
   dbaron: I don't know if it's that that interoperable?
   annevk: I don't see how reorganizing is going to help us vs. implementors
           working on it.
   annevk: there isn't even much discussion
   dbaron: also, authors don't use the OM that much
   tantek: isn't it a chicken-and-egg problem; they don't because they can't
   tantek: Tab was complaining about how many obsolete drafts we have. we
           have this problem here too e.g. DOM L2 Style.
   tantek: I'd like to see something that reflects the interoperable state
           of the world
   dbaron: I think authors don't use the OM much, even what is interoperable.
           Authors tend to use the model that styles are static and they
           dynamically change the content-- and I tend to think that's a
           good thing.
   dbaron: if there isn't a lot of demand for it, should we spend time on it ?
   tab: I know that there is demand for a new value-based om that wouldn't
        be string-based. It's a popular author request that is currently
        done through libs like jQuery
   tab: we know that there is a use-case in that area
   dbaron: yes, I've seen author demand for this, as well as for variants of
           computed style as well as some author demand for the set of matched
           rules for an element
   dbaron: I can't recall authors asking for poking through rules inside a
   tab: that is useful for CSS polyfills
   annevk,dbaron: except the features you want to polyfill are dropped
   fantasai: I'd like to document what we have right now
   fantasai: and the new interfaces would be in a separate document
   fantasai: and we can move the bit that's implemented in CR and beyond
   kimberly: we as implementors are looking for guidance; we need a document
             that reflects what browsers do in order to build compatible
   [discussion about the fact that DOM Level 2 Style is on /TR and has not
    been obsoleted by anything]
   howcome: are we interested in investing this kind of effort ?
   sylvaing: It does keep coming back.
   glazou: But it keeps coming back. We've been discussing this since 10
           years ago.
   glazou: Anne invested a lot of time in this spec cleaning it up
   glazou: Form an implementation POV, we're almost exactly at the same point
   dbaron: There's a bunch of things in anne's spec that have been implemented.
           It's just not the core stuff
   dbaron: I think there are things in the spec that have been implemented.
           but a number of things have not been
   discussion of poking around the style sheet
   discussion of how many people need editing functionality
   alan: do we need a testsuite to get implementors interested ?
   sylvaing: There's enough pain that this topic keeps coming back, but not
             enough that implementers are investing in it
   tantek: since we agree to have obsoletion noticed in old modules that
           aren't maintained, I think we should do that for DOM L2 Style
           and link from the latter to CSSOM
   bert: but then there is nothing stable anymore
   tantek: but that is reality and would be honest
   annevk: that would be a service to the community, I think. They would at
           least know what we're working on now
   bert: it's better but not enough
   annevk: we should at least have a link to the obsoletion email you sent
           in 2003; adding a link to the CSSOM would be helpful, but not
           critical imo
   glazou, jdaggett: the specs are not understandable or usable hence the
                      attraction of jQuery as a way to use the OM
   jdaggett: is it OK to mark specific sections as obsolete at least ?
   glazou: yes
   jdaggett: so CSS values in DOM L2 Style in marked invalid, not the entire spec
   hober: that can also be marked at the top
   glazou: I don't want the entire document to be obsoleted
   plinss: is the problem unaware of the Editor's Draft ? is that the problem ?
   <fantasai> various people giving examples of this actually being a problem
   dbaron: there are 2 threads here; the value API and the representation
           of style sheets e.g. at-rules
   glazou: I don't understand why we don't have a requirements document for this
   RESOLVED: add a notice to the top DOM L2 Style indicating portions of the
             spec are obsolete linking to Bert's email and linking to CSSOM.
             Also, the specific obsolete section of DOM L2 Style must be marked
             as such
   ACTION Tab: Draft note on DOM Level 2 Style
   <trackbot> Created ACTION-395
   fantasai: once we agree on the draft notice, we can resolve a PER

   dbaron: the things people do with jQuery relates to the value API; editing
           tools need both the value API as well as the stylesheet traversal
           interface. The latter is not that hard but the current specs are
           inconsistent and poorly written, but 80% right
   dbaron: we decided to throw out the value API and rewrite it but the new
           API is a draft that no one has implemented
   annevk: Only part of the values API is there
   dbaron: If someone tried to implement it, what would happen?
   sylvaing: does one need to implement it in the engine or could it be
             experimented with in JS ?
   jdaggett: If it's not a big API...
   annevk: it could be done in JS
   dbaron: It's a pretty big API
   jdaggett: It seems we have two modules here. I keep hearing that we need
             something in a firmer state, and the Values API is not in that
   annevk: I don't think we need to split the draft.
   jdaggett: I think the stylesheet traversal API has more impact on new
   dbaron: it depends on the feature. if we implement the new values API,
           this would impact CSS3 Fonts features e.g. font-feature-settings
           would need a whole object model
   jadaggett, dbaron: there is no consistency of design among the at-rule
                      definitions across modules
   annevk: shouldn't that be solved by review ?
   tab: we should have guidelines before review
   dbaron: the OM for keyframes rule looks different from what's in 2.1 but
           it was already implemented so I followed the same model.
   <anne> I have to go in four minutes
   dbaron: as far as we can tell, it's unclear that the people who use these
           interfaces care about these inconsistencies
   Florian: The people who care do not give sufficient feedback
   dbaron: one of the ways we judge interest in things is based on feedback
           on obvious problems
   glazou: and maybe they don't have to comment because there are shims like
           jQuery which deal with the problem
   plinss: If something is bad enough, people look at it and decide it's way
           too unstable, way too much of a mess, to comment on
   dbaron: that is the values API, not the stylesheet interface. they're
           not the same thing.
   fantasai: I edit a lot of specs. I don't know what I need to put in my
             spec about serialization, OM, values API. I don't know what
             to do in CSS3 because there is nothing stable for me to build
             on top of
   fantasai: once I have something stable then I can reference it and update
             my modules.
   fantasai: maybe serialization is stable enough so I could reference it but
             if stable and unstable things are in the same module I don't know
             what to do
   <tantek> I've updated http://wiki.csswg.org/spec/cssom with notes about
            what people have claimed are author demands. More evidence /
            statements welcome.
   jdaggett: I think we need to have someone else co-edit to ensure we
             document implementation reality
Scribe: fantasai
   glazou: John is proposing to have a document reflecting current
   glazou: I'm not sure that the current implementations are so inconsistent
           that this is not doable
   glazou: Getting a stable spec, that only consists of the stable specs, I
           don't know that that's useful
   Florian: If you ask me what the stable parts are, I have no idea.
   jdaggett: I think there is value here. If you have a spec that focuses
             the set of features that have implementations, even if they are
   jdaggett: Trying to iron out those variations, that's value. Even if it's
             not sexy, it's still value.
   jdaggett: I don't know that it has to be another spec, but we need to
             get the existing CSSOM spec ...
   glazou: I think what you want is a better use of our time to add warning
           notes to the current DOM Level 2 spec than what you're proposing
   arronei: This is what our test suites do
   Tantek: I'm going to object John's assertion that we need anotherco-editor,
           the editor's draft was lately updated
   jdaggett: Editing the draft doesn't ensure it's moving towards something
   Tantek: Let's work cooperatively within existing mechanism
   Tantek: Oftentimes when another editor is needed for something, it's not
           due to ...
   Florian: Anne is not interested in documenting the existing bits
   tantek: writing down what works today, I just want to establish how. can
           we write it down on the wiki page ?
   tantek: I just want to capture the request that we want to know what
           implementations do
   sylvaing: Anne is definitely the right guy for the values API, but he's
             not interested in doing the documenting existing stuff
   sylvaing: Putting things on a wiki page doesn't make them happen
   szilles: you can't tell whether they'll happen until you put them there

<br duration=5m/>

IDPF Joint WG meeting

   +Brady Duga
   +Bill McCoy
   +Peter Sorotkin
   <duga> AAL charter: http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter
   duga: The Advanced Layout group of IPDF is going to begin work shortly
   duga: our members have been clamoring for more powerful design, adaptive
         design, for page layout
   duga: Right now when people want to do high design, they go back to
         JPEG, abspos, things that don't work well for multiple-size devices
   duga: A proposal was made by adobe in PEU3 for more adaptive layout
   duga: Didn't make it into 3, but portions of it turned into CSS Regions
         and Exclusions
   duga: There's still a whole bunch of things not in those specs
   duga: There's still a lot of clamoring for advanced adaptive layout
         features in a very short timeframe
   jdaggett: There's a big disconnect that I see between the way EPUB makes
             their specifications and the work that actually needs to get done.
   jdaggett: If you define a schedule and then try to match features to that
             schedule, anyone in software will tell you that that doesn't work
   jdaggett: Especially where complexity is involved
   jdaggett: And when you talk about complex layouts in CSS, that's by
             definition complex
   bill: The reason we're here is to make sure we have a connection
   jdaggett: A schedule-driven process will not get you something that will
             be interoperable.
   jdaggett: The way EPUB has operated In the past is on-schedule. Whatever
             you're delivering is built on quicksand
   <Bert> -> http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter
             IDPF Advanced Adaptive Layout working group charter
   jdaggett: You're referencing working drafts of this WG, and those change
   jdaggett: Rather than talk about scheduling, it's much more important to
             look at for the work of this group, where are the problems that
             are holding up things. And contribute from that angle. Rather
              than talking about scheduling
   jdaggett: I think basically proposals are here. Would be more helpful if
             members at EPUB were focusing on what is needed to work out the
             problems associated with the various features that are being
   jdaggett: I see this a lot in vertical text layout. EPUB comes with a
             feature list, but when you have to figure out how these things
             actually work, participation is lacking.
   bill: We want to make sure participation is there and we contribute to
         broad open web andd assume open web wants to evolve to handle needs
         of publishing
   bill: Over time we're getting closer and closer.
   bill: EPUB2 referenced subset of CSS
   bill: EPUB3 took a different approach. We followed the recommendation from
         the liaison to prefix things, etc.
   jdaggett: We also had people from this group talk of not referencing WDs
   jdaggett: Do what you want, but this will not get you interop
   bill: The market demands were moving on anyway

   dbaron: One thing you mentioned was seeking eventual alignment with web
   dbaron: One of the dangers there if you take a snapshot of a WD is that
           either one of two things will happen
   dbaron: one is that the set of implementations doing EPUB will be different
           from Web technology, or same implementations plus flags
   dbaron: And you'll end up with converging implementations within EPUB and
           converging implementations within the Web, and those two groups
   dbaron: The other possibility is that you'll have common implementations,
           and one or the other set of specs will end up being ignored in
   szilles: I completely agree with points by john and david, but we are
            sort of faced with 2 orgs trying to find an effective mechanism
            for cooperating. They have different constraints.
   szilles: The warnings you express are valid
   szilles: But more productive than trying to change how they're operating,
            is trying to minimize these kinds of issues or find ways for
            effective cooperation.
   szilles: In particular one of these seems to be for EPUB to prioritize
            the feature list, so if we can only tackle some of it we know
            what to tackle from your side
   glazou: Since I'm myself writing an EPUB2/3 editor, taken a look at all
           the editors, tools, renderers.
   glazou: Most of them are based on web engines
   glazou: The Web industry and EBOOK industry share the app layer
   glazou: I don't think there are going to be two different layers of runtimes,
           one for web and one for ebook
   bill: We took decision in EPUB3 on buying that assumption
   bill: Could have moved towards more DocBook like vocab. Instead reference
         HTML5/CSS all-in
   bill: Taking however the reality that some of those won't be fully baked
   bill: Decision was popular with vendors, lead to things like Apple iBooks
         based on WebKit
   bill: Downside is that widely adopted modules that are WD
   bill: CSS2.1 is baseline, but 9 modules referenced by EPUB3
   bill: But all of those have some implementation
   bill: We would like guidance from CSSWG.
   bill: We are not W3C.
   bill: As soon as there's cross-browser implementation, we're using those
   bill: We're here today because we want to develop an optional add-on
         module to EPUB.
   jdaggett: I'm telling you that within this group we've had ppl say
             "we have to do this this way because impl for EPUB already
             do this this way"
   jdaggett: That's not the right way.
   jdaggett: If it's something that's fundamentally wrong, I don't buy
             that argument.
   bill: We took the decision, knowing that our maintenance strategy for
         unfinished specs, would be to rev EPUB .1 .2

   jdaggett: Go back to what brady said, Adaptive layout is a minefield.
   jdaggett: It's very complex, it's hard to get right. if you start
             snapshotting, you will run into trouble.
   glazou: You said cross-browser implementations, you'll add to EPUB
   glazou: It's not because we have cross-browser implementation of
           something at some point that the spec is stable
   glazou: for us the only moment we can say something is stable enough
           is when we move from CR to PR.
   glazou: The good example is gradients.
   glazou: We have four incompatible specs for gradients.
   glazou: At some point we may have 2 or 3 compatible implementation
   glazou: If you rely on temporary stuff, if it's not a recommendation
   Florian: I think Steve is a valid point. If we have a schedule, a
            feature set, and a quality requirement
   Florain: i.e. spec is advanced enough
   Florian: We can't have these things all at the same time
   Florian: Prioritizing your features is important.
   Florian: We can try to push ahead faster with higher priority things.
   Florian: We have a lot of things, some of which you care, some not so much.
   Florian: We won't exclusively work on your things, but we can give it
            more weight
   Florian: We are quality-driven, you are schedule driven. The only way
            to work together is prioritizing

   smfr: the other issue of snapshotting WDs is that it puts a burden on
   smfr: We have to maintain old behavior for compatibility, that we
         really don't want to have to maintain
   smfr: In Webkit we try to avoid flags, "we are rendering epub"
   smfr: We might not even be aware that EPUB snapshotted some draft spec
   Markus: I totally understand where you guys are coming from. Because if
           you don't push the needle, you wind up with ... Amazon
   Markus: I think the solution to this problem is prioritization Florian
           brought up. So if you keep separation of content and style
   Markus: We of course don't work on content
   Markus: That is best model to work forward
   <mmielke> Correction: Amazon is having a model that is based on REC specs
             (CSS2.1 capabilites) and do not rely on specs in working drafts

   szilles: In category of requirements, might be useful to look at what
            Peter proposed to IDPF as kinds of things publishers are
            looking for
   bill: Charter does list some priorities, and I expect next few days we'll
         see more concrete proposals
   bill: We're defining these as a vendor extension, but will show what we
         might depend on.
   bill: You might not do adpative layout on our schedule, but we depend on
         calc(), or CSS regions,
   bill: We need to work together with those.
   szilles: We've had demos from MS and Opera of paginated documents, so
            they're very much on the structure.
   (using CSS)
   szilles: They are going in that particular direction, so showing the
            PGT sort of things is relevant. It's written on top of HTML
            and CSS

   hober: I think echoing florian and john...
   hober: I think there's a diff between source of dependence of WDs in
          EPUB3 and this new high-design module whatever
   hober: It's one thing to epub-prefix writing modes
   hober: But this last couple days, I've seen some very interesting and
          very different proposals for doing these kinds fo layouts
   hober: so different that even if we make an amazing amount of progress
          in the next 6months, I have no idea what it's going to look like
   hober: Baking in something like regions is petrifying.
   fantasai: our specs have different phases
   fantasai: you really don't want to depend on something that's not in the
             stabilizing phase
   fantasai: all the layout proposals are in the completely unstable phase
   bill: If you say we shouldn't reference something, then we won't.
   bill: We want to have publishers avoid creating proprietary features

   howcome: I agree with steve there is strong interested in moving to
            on-screen pages, so we have common interests
   howcome: My concern with some of these e.g. regions is that they are
            quite complex and they will take a long time to stabilize
   howcome: My demo shows that we can do 90% without adding a single
            property in CSS
   bill: The pages things in Opera is awesome. I was showing it at a
         conference just recently.
   bill: However, that's not what makes EPUB tick. The EPUB content isn't
         just content that paginates.
   bill: It's ... orchestrated
   bill: manifest
   bill: I welcome paged views, but it's not what EPUB has
   bill: That's EPUB2 level. We have picturebooks, magazines, etc.
   bill: template-based stuff
   alex: I might be a little confused with the background, what you're saying
         "us", is this EPUB or is this advanced adaptive layout charter group
   bill: My immediate agenda item is coordination around advanced layout,
         but first issues raised are about general principles of IDPF
         standardization practice
   bill: IDPF is a trade associate of publishers and ppl working in publishing.
         Very focused on publications, with a range from trade books to more
         complex publications
   alex: ... how much you're going there.
   alex Around 10 years ago, MS had an epub format which was subset of HTML+CSS
   alex: It seems that in advanced layout is that you're willing to very
         divergent standardizing of something
   alex: is this something we should do in this group?
   bill: that would be fantastic
   bill: We asked W3C staff for review of our charter
   bill: we didn't receive comments on the charter from CSSWG members
   bill: We're trying to meet the timeline of our members
   bill: We are a date-driven organization, not so much quality
   bill: ... We're trying to get things out the door, and will accept the risks
         of some things fail.
   bill: more like a startup
   alex: You can have 8-month completely standard for a paginated document
         book and magazine layout and it will be ready for publication and
         have implementations? *skeptical*
   bill: yes. we're generalizing work that a member has already done
   peterS: I'm from adobe, I'm member of IDPF WG.
   peterS: We have a lot of differences, not only how the standards is driven,
           but also how these documents actually live
   peterS: Complex websites get updated daily. Books don't
   peterS: The JS on the Web, you can't afford for books on the web.
   peterS: You want to publish it and forget about it, not maintain it.
   peterS: Puts a lot of pressure for having declarative ways of doing things.
   peterS: pressure is very differernt
   peterS: I was voicing a lot of similar concerns about referencing CSS WDs
           in IDPF
   peterS: A lot of these references come from East Asian market
   peterS: There are competing standards there. If we give up and not do it
           for 2 years, it's saying we won't do EBooks with CSS.
   peterS: You're lucky, there is no CSSX, nobody is trying to fork it or do
           something completely different.
   peterS: We have this problem in ebooks, we cannot ignore
   peterS: One of our considerations for advanced layout proposal is to make
           sure it can be implemented today on top of existing browsers
   peterS: As long as we can do it today, we can be sure we can do it in
           future borwsers.
   peterS: That simplifies the javascript.
   peters: You'd need to augment your presentation with JS
   peters: There is no requirement for JS in the publishing world as in browser
   peters: It's possible to move forward with moving creating more properties
           and features without touching the browser at all

   Bert: My conclusion so far is that we can only influence each others time
         scales so much, so how do we limit the damage?
   Bert: two ways to do that
   Bert: One is to have timely info from EPUB of what they need, so we can
         within the little flexiblity we have, to work on their things faster
   Bert: Also would be a good thing if we can give advice regularly to EPUB
         to avoid that they make too many mistakes
   Bert: Steer you into something that's a little bit safe. How do we make
         sure that happen?
   Bert: Way to do that is liaisons, need people on both sides to communicate
   Bert: maybe I should take some responsibility for that, it's in scope for
         my work anyway.
   Bert: Maybe bring other people along to join meetings/telecons
   Bert: Talking to each other is best way
   Bert: Peter said books cannot be changed. That means you need even more
         stable standards than the web browsers.
   Bert: So you really need things that are extremely stable
   Bert: You want to buy a book and 10 years still read it
   bill: We had a lot of help from fantasai for EPUB3, but she was clear
         that she couldn't represent full bandwith of CSSWG
   bill: I think future of publishing in digital world is up for grab, some
         overlap with widgets and webapps
   bill: various points of synergy
   plinss: I'm in the process of joining the EPUB group. I think you'll have
           interst in CSSWG to work with you guys. There would be good to
           have ppl from EPUB to join us on a regular basis
   jdaggett: To your point about schedule and having things that you need to
             ship immediately.
   jdaggett: that's fine.
   jdaggett: In the case of adaptive layout, you need to communicate to ppl
             in your organization, that by standardizing on your time scale,
             you pretty much guarantee incompat with future web standards
   peterS: The point we're trying to achieve, you can develop an EPUB UA on
           top of the browser using JavaScript
   jdaggett: Whether that's possible, I cannot tell you
   jdaggett: It's not standardized
   Florian: Sometimes specs are more stable and not marked at such. In this
            case we're talking about stuff that's really really unstable
   hober: What bill said earlier, that EPUB is trying to be very agile
          organization. Think it's a very great term, want to hit on the
          viable part
   hober: Like Florian said, if you have [3 things], there's inherent tension
   hober: To resolve you're best off dropping features
   bill: We're clear on that, but our main focus of where compat is
   bill: We want that markup produced by tool like InDesign will work in
         the future epub readers
   bill: More important than compat with Web

   szilles: Let me try to say what peters was saying in slightly different words.
   szilles: there is a presumption in a number of the comments that the
            features that go into EPUB3+ are features that need to go into CSS
   szilles: What peter is saying is slightly different. Peter is saying that
            CSS today provides enough capability with JS to take a declarative
            language and present what you see on the screen
   <tantek> I'm a little confused about the confusion around communicating
            stability of CSS specs, isn't that what Beijing did/does (2007,
            2010) ?
   szilles: Adobe has been trying to pieces of that mechanism that are hard
            to replicate in JS and migrate them into CSS
   szilles: on a timescale that fits with CSS. Because there are solutions
            that work in the interim
   szilles: Regions would make these demos easier to do.
   alan: But these demos don't depend on any of the new stuff
   szilles: There are other things like line grid that can't be done in JS,
            and we'd need to move within CSSWG
   szilles: So agreeing on those pieces is the most important thing we can do
   Florian: What you said is important to me. Your highest priority is not
            necessarily what should be our priority, since you can do much
            of this without us.
   bill: ...
   bill: From my pov, even if something's implementable in JS, if we
         nevertheless use a similar markup... or create our own, it could
         be a problem later
   bill: Don't want to sweep that under the table and say we're not worrying
         about it.

   dbaron: You've mentioned that when you did EPUB3 it was essentially a
           different format from EPUB2. Is it backwards compatible?
   bill: You could write EPUB3 that works on EPUB2 reader. Also EPUB2 books
         must work in EPUB3 reader
   dbaron: What if EPUB3 depends on a technology that goes in a different
           way than this CSSWG goes?
   dbaron: Would future versions of EPUB require the divergent technology?
           What CSSWG creates? Both?
   duga: In EPUB3 we tried to point out pieces where things are likely to
         change incompatibly.
   duga: We've committed to advancing with CSS, and pointing out to authors
         to beware of these potential changes
   bill: EPUB4 might say a ruby property is deprecated and nonconformant in
         content, but UAs must still implement it

   Alex: Some questions
   Alex: I'm really surprised we're talking about liaisons and you doing
         some significant amount of work, but also we're doing here
   Alex: I'm surprised that *I'm* not involved, as someone making major
         progress on Regions
   Alex: why not talk to us?
   jdaggett: alex edits regions
   alex: Whatever.. finish regions sooner, there are opportunities for us
         to make parallel progress
   alex: We here need help as well. kindof depressing that I discuss stuff
         with Vincent and nobody else contributes
   bill: regions is 25% of advanced adaptive layout
   <tantek> what's the other 75%?
   <stearns> tantek: see the charter that was linked above
   Florian: Regions is a good example. Because it's one of the difficult
            pieces here, only a few people understand it rest are waiting
            until they're done
   Florian: in your group are working on the same thing, participating
            here will make these ppl feel a lot less lonely

   <tantek> stearns, captured on the CSSWG wiki: http://wiki.csswg.org/spec#idpf-epub

   alex: My second point is, it seems that something that will get produced
         in a very short time and targetted at a very specific applications,
         seems very similar to a company shipping product with publicly
         document format, designed by one company
   alex: we've done this with MS office format. developped by one company
         for its purposes
   alex: Seems similar to me.
   alex: If you don't have any requirements for that format to be tied to
         CSS WG, does it belong to W3C?
   alex: Would it be your format that is documented and supported by reader
         applications, and whatever CSS or HTML requires has ...
   alex: ... support forever

   glazou: I have question of prefixed properties you're going to use
   glazou: Say you'll sync with us and drop things not used anymore
   glazou: What if you adopt, e.g. gradients now.
   glazou: Gradients are going to drastically change in next 12 months,
           at which point your gradients are entirely incompatible
   glazou: It's not about dropping version, but changing the value of that
   glazou: The books in the old version would be incompat with new one
   bill: Alias would be maintained.
   bill: One option, reader detects 3.0 vs 3.1 and ...
   peters: We would wait until you reached CR, even if we have our epub gradient
   peters: Once you reach CR, we would import your stuff and be done with it
   glazou: It's unlikely between editing tools for EPUB would be different
           than Web
   glazou: You chose HTML+CSS
   glazou: Again the rendering engines are going to be the same
   glazou: so having -epub-prefixed properties does not make sense
   glazou: Editing tools won't deal with that
   glazou: You are not doing editing tool, you're doing a converter
   bill: we agree with premise of minimizing prefixed properties
   bill: Only 3: text, speech, and ruby are used prefixed
   bill: And those are generally for east asian typography
   bill: we would prefer not to have prefixed properties, no question
   bill: We want EPUB ot be portable documents based on open web

   szilles: Actionable items I heard were to increase liaison participation
            in both groups
   szilles: Bert volunteered to get involved in IDPF. Can we ask IDPF group
            to expand liaison with our organization?
   glazou: We have a lot of things to discuss together.
   bill: A mechanistic point, several of the key IPDF members have presence
         in CSSWG
   bill: Adobe, Google, Apple
   <tantek> Can we invite IDPF to directly participate in CSS spec discussions
            on www-style?
   bill: Might ask for redundant representation, but not up to us
   glazou: We need coordination between two groups. Not the same thing as
           coordination between members.
   szilles: Getting more participation from ppl not reprsented at the table
            today, more likely to have informative opinions and users
   szilles: We have a lot of technologists at the table, far less users.
   szilles: Understanding what's being asked for is a difficulty
   Joint meeting closed.
Received on Monday, 28 November 2011 21:59:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:10 UTC