- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 13:41:43 -0800
- 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.*
CSSOM
-----
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 ======
http://www.w3.org/2011/10/31-css-irc#T16-00-52
http://krijnhoetmer.nl/irc-logs/css/20111101#l-708
CSSOM
-----
Scribe: sylvaing
+annevk
<fantasai> http://dev.w3.org/csswg/cssom/
annevk: the CSSOM is a collection of various CSS features exposed through
script
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
on
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
specify
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
stylesheet
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
devices/platforms
[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
state
annevk: I don't think we need to split the draft.
jdaggett: I think the stylesheet traversal API has more impact on new
features
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
implementations
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
inconsistent,
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
stable
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
proposed.
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
technology.
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
diverging
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
reality
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
features
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
implementers
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
there.
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
property
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