[css3-gcpm] full comments on the last ED (with Variables inside...)

(cc:ed to Tab Atkins because Variables are discussed)

I have finally taken the time to review CSS 3 GCPM line by line,
concept by concept. I have important comments to make about it and
I am again calling for a massive revamp of GCPM. It just cannot be
published as is.

   Maybe an harmonization of string-set with CSS Variables is doable.
   'string-set: title contents' becoming 'set-title: contents' that is
   more readable and in my opinion cleaner. I understand it won't be
   possible any more to define multiple strings in one rule only, but
   that's in fact something good for authoring environments.

   'content-first-letter' definition is not clear enough, it could
   specifically retrieve the textual content of the ::first-letter
   pseudo, that would be clearer.

   Prose says the scope of a named string is the page of the element
   but since the property applies to all media, does it mean the scope
   of a named string in a 'screen' medium is the whole document? In
   that case, they define document-level variables that will collide
   with CSS Custom Inherited Properties (aka CSS Variables) in the mind
   of users.

   wow, issue 1 for env(date) is a very serious one... I think the UA's
   locale should be used in all cases.

   'first-except' in section 2.1.2 is quite a bad name. Hard to
   understand. Can we try something better? I would like to see a clear
   use case of this.

   Running elements in section 2 are an incredible hack using position
   and content properties just to hide th fact they are really defining
   content flows. If I take example 10:

     title { position: running(header) }
     @page { @top-center {
       content: element(header) }
     }

   this EXACTLY means

     title { flow-into: header }
     @page { @top-center {
       flow-from: header }
     }

   but the latter is readable, not hacky. I understand first response
   to that will be that running elements are copied into the flow AND
   can remain also in place. This is an extra feature that can be
   *easily* added to named flows. Similarly, the fact that multiple
   elements into a flow aggregate into the flow's recipient instead of
   resetting the flow's recipient each time can be easily added to
   named flows.
   Since running elements are explicitely said to be able to be copied
   into a flow AND remain in place in example 11, a positioned element
   cannot run into a page margin box. This is a rather drastic
   limitation. Furthermore, section 2.2 example 11 seems to show an
   extension of the 'position' property to multiple values that is not
   described nor referenced.
   All in all, running elements here seem to me an incredible hacky and
   a very weak solution in comparison with named flows. I suggest to
   drop this in favor of flows modulo addings the necessary extensions
   to flows for copy handling (to match example 11 feature) and
   resetting (to match the second argument of element()); that will
   serve footnotes handling (see below).

   The second argument to leader() in section 3 is a hack to avoid
   applying text-align property to ::after and ::before. But if you
   consider the fact leader() is currently the only notation allowing
   to extend the width of such a pseudo-element from its minimal-width,
   text-align is easy to deal with in this context, simplifying the
   model and getting rid of a redundant parameter.

   Target-counter, target-counters and target-text are nice features
   but that seem to me a bit hacky. We should brainstorm a bit to see
   if the currently proposed model can be improved. In particular, I
   think the syntax quite ugly. I am also concerned about the fact this
   will not work of external resources (let's say if in example 19 the
   href attributes targets a different document).
   I think Custom Inherited Properties (aka Variables) can help
   here. For the time being, we're only able to retrieve the value of a
   property but we could be in the future able to retrieve a variable
   value on an arbitrary element. So if the target of the link is a h2:

     a::after {
       content: "(see page "
                var(attr(href url) pageVar) /* note the whitespace */
                ")"
     }

     h2 { var-pageVar: counter(page, decimal); }

   Don't focus on the syntax itself, in particular var(), focus on the
   model. It's simpler and has a greater adherence to other specs
   inside the WG.

   Footnotes as defined in section 5 are so magic it's even mentioned
   in 5.7's title... They require many new concepts instead of reusing
   what we already have on the radar. Positioning the footnotes area in
   a page (as presented in examples 27 to 29, please note there are two
   example 28!) requires deep extension of the float property.

   A much better model, simpler and far less magic is achievable using
   named flows and regions. It is even more consistent with the concept
   of running elements described above! As they're in the spec now,
   footnotes seem to me unacceptable.

   Bookmarks in section 7 seem to me an incomplete mechanism at this
   time. I understand this is to be handled by the UA but how is it
   retrieved? How does the UA create the bookmarks list? How can the
   bookmarks list be generated (as in generated content) into a
   specific page for instance? This section requires much more details,
   clearer use cases with rendering examples and potentially a complete
   revamp, including technically. I'm not sure the current model is
   useable as is.

   Section 8 has nothing to do here. Should be in the CSS Print Profile
   in my opinion.

   Section 10 has a long history with Opera slideshows. I think
   implementation has shown validity and simplicity of the model. I'd
   like to hear from other implementors though.
   Issue 7 is right, 'paginated' is better than 'paged'

   Section 11, this is not stylistic and not in the scope of the CSS
   WG. I also doubt we should be the only ones caring about that. The
   proposed solution seems to me incredibly dangerous, I don't like it
   at all and I feel this section should be entirely removed from
   GCPM. The syntax evolved between last WD and this ED, showing this
   feature is not stabilized. As far as I am concerned, I plan to
   object to a LC release of this document if this section is in,
   this is outside of the scope of your Charter.
   Many people have expressed concerns about this since the day it
   was added to the GCPM draft. I think the CSS WG should say
   explicitely if this is stylistic, if it should stay here, etc.

   Section 12 should be moved to next level of multi-column. It goes
   FAR beyond the previous versions of the GCPM WD. It is not specific
   at all to PagedMedia and Håkon's demos I saw were all made on screen
   in a non-paginated mode.
   Whatever happens to that section, I express DEEP concerns about the
   technical model even if I agree with the feature. This should be
   discussed in the CSS WG before any kind of WD publication.

   I don't understand the purpose of section 13. If there is an
   alternative syntax to discuss, that should be done outside of the
   spec among the Membership.

   I just could not believe my eyes when I discovered section 14 about
   Exclusions. We have a WG Charter listing CSS Exclusions and Shapes
   as a deliverable and Håkon's ED contains (still contains?) a totally
   incompatible model. I am asking this section to be deleted and
   contributions to go into the Exclusions and Shapes basket, *as
   described in the CSS WG Charter* section 2.2.

   Similarly, I discovered sections 15 and 16. Same concerns.

   (this line explicitly to Håkon: don't make the mistake you did wrt
    my affiliations again, I will NOT accept it. See what I mean?)

   Globally, these 3 sections seem to me too column-specific and they
   seem like using a shoehorn to make regions and exclusions fit into
   multicol. I don't understand this. The current CSS Regions and CSS
   Exclusions and Shapes proposals work perfectly inside multicol. Why
   do we need a more specific solution here? Just to prove multicols
   can be extended to create arbitrary regions? How can someone call
   example 80 in GCPM spec "columns"? Seriously? I can't even
   understand how in that example the top region is defining an
   exclusion into the lower ones. There is nothing in the CSS to handle
   that.

   Again, are section 18 to 20 a ED or a thinking-out-loud proposal? It
   seems to be the latter. If it is, it should be in www-style, not in
   a spec visible to the public.

   All in all, GCPM seems to me more a "kitchen sink" document
   aggregating unrelated things that matter to Opera and/or YesLogic
   than a real "Generated Content for Paged Media" spec. Because of that,
   I disagree with a release as is, even as a new regular WD.

</Daniel>

Received on Wednesday, 20 February 2013 12:37:27 UTC