W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-multicol] new editor's draft

From: Shelby Moore <shelby@coolpage.com>
Date: Sat, 23 Oct 2010 09:50:13 -0400
Message-ID: <21497c30d29a57cd00864c81818d6458.squirrel@sm.webmail.pair.com>
To: "Håkon Wium Lie" <howcome@opera.com>
Cc: www-style@w3.org
> Shelby Moore wrote:
>  > I found one typo...
> First, thanks for you thorough reading and the time you have spent
> writing up your comments. As you have seen, several of the changes
> done in the last revision are due to the points you make -- even if I
> don't always use your proposed wording.

Thank you also.



>  > > within the multicol element. Also, if a setting on this
>  > > property pushes the element outside a multicol element, this
>  > > property will have no effect.
>  >
>  > Where is the logic on this please?
> By setting 'column-span: all' on an element, there's a chance you move
> the element outside the column box. If so, you don't really have room
> to make the element span, and it should instead be displayed normally.

Sorry to be pedantic, but could we improve the wording to make it more
readily understood? The second sentence is redundant? Also "has no effect
on elements..." is misleading, as it implies there is something broken or
limitation with the property itself.


"This property has no effect on elements that do not fit entirely within
the multicol element. Also, if a setting on this property pushes the
element outside a multicol element, this property will have no effect."


"This property is ignored when applied to elements that would cause them
to not fit entirely within the multicol element."

>  > > 6) The break-* properties have been given their own h3 element.
>  >
>  > Ditto this, where is logic?
> This was just an editorial change to give the bread-* properties their
> own headline in the spec so that they can more easily be found.

Oic, hehe. Sorry.

>  > I like that you removed the conflation of overlow due to constrained
>  > height and pagination, i.e. you removed "In paged media, the column
> height
>  > is constrained by the size of the page.".
>  >
>  > However, you still discuss pagination in the section, but the section
> is
>  > still entitled "8.2. Overflow outside multicol elements".
>  >
>  > Overflow has a specific meaning in CSS, we must not dilute and conflate
>  > with pagination. Separation of concerns is a fundamental concept I
> think
>  > we all strive for.
> Overflow and pagination are related in this case. Also, it must be
> possible to refer to a topic in a section even if it's not listed in
> the heading.
> So, I don't think it necessary to include "pagination" in the heading,
> but it doesn't hurt either. Thus, I have revised the heading in
> section 8.2:
>   http://dev.w3.org/csswg/css3-multicol/#pagination-and-overflow-outside-multicol

I see you also removed " and multicol elements" from the overall section


I find the result to be agreeable.

I understand that mentioning about pagination in the context of that
overflow discussion is more fluent.

I personally would have entitled Section 8: Overflow and Pagination,
instead of just Overflow, but I am okay with what you have now.

>  > It is really important to not confuse people more, because CSS is
> already
>  > way too confusing. The reader will be wondering what the heck does
>  > pagination have to do with overflow.
>  >
>  > I really think you would do best to instead make a section 8.3 for
>  > pagination.
> I disagree, it's natural to discuss how content is moved to the next
> page in the same section as overflow.

Agreed more fluent.

I am just trying to prevent the case that happened to me, where when I
clicked the TOC to that section, I thought I was reading about
'overflow:?' and then I was trying to figure out what pagination had to do
with 'overflow:?'.

But now that you have corrected the inconsistencies that were there
previously, and with the clear separation of two concerns in the
sub-section title, I find I would not have the same confusion (conflation
in my mind).

>  > > I've been tempted to introduce the term "multicol box" to mean "the
>  > > content box(es) of a multicol element". That would be slightly more
>  > > accurate. However, I think the current text works.
>  >
>  > What is the difference between the "content box(es)" and the "column
>  > box(es)"? I can understand the multi-col element has its own content
> box
>  > which contains column box(es), but how does a single mult-col element
> get
>  > multiple content boxes?
> Pagination. One mulitcol element can result in (say) three mulicol
> boxes, one per page.

Yeah that is what I thought you meant, and I find that whole concept
confusing to grasp (not now, but before I had so many discussions on this
mailing list). In fact, I think it may be the wrong metaphor. I will
explain below.

In any case, continous media and paging media diagrams would really help
(something similar in presentation to the diagram of the box model).

The way I think of it in my mind is that multicol element is being
replicated on each page, then the content is being over-flowed from one to
the next. But I realize the element itself is not being replicated. How
best to explain it so it assimilates in the mind readily?

That is why I like the concept of the "column row". Actually what you have
due to pagination is not multiple multicol boxes, but rather you have one
long multicol box that spans multiple pages, then you have multiple column
rows, with one row per page. Is the multicol box allowed to have different
widths on each page, or just different column widths? I think the latter,
and thus that suppports my claim on the metaphor I suggest in this

If you explain it that way, IMO the spec will be more successful in
gaining comprehension.

>  > Also why are technical terms not in italic, so I know when I am reading
> a
>  > term which has a definition, e.g. column row height or column box.
> Technical terms are marked as <dfn> elements the first time used, and
> explained. Thereafter, their use in the text should conform with the
> definition but they are not called out. This is consistent with the
> other CSS specs.

I am making a general suggestion for all CSS specs then. I think they
should be called out every where. I can change my user CSS override for
the page, if I want to turn off their rendering so called out.

Because personally I want each metaphor to be delineated. I can read my
faster that way, because I can quickly assimilated the terms, versus their
normal meanings in English.

>  > Another reason I find CSS specs very hard to parse, because I can't
>  > quickly see where are the defined terms.
> Would you really want to see the definition of all terms always?
> Here's a random sequence from CSS 2.1:
>    All levels of CSS - level 1, level 2, and any future levels - use
>    the same core syntax. This allows UAs to parse (though not
>    completely understand) style sheets written in levels of CSS that
>    did not exist at the time the UAs were created. Designers can use
>    this feature to create style sheets that work with older user
>    agents, while also exercising the possibilities of the latest
>    levels of CSS.
> About half the words in that text could point to some techincal
> definition. I'm not sure the extra effort in writing the spec would be
> worth it.

Yes I would like to see which are terms and which are not, because I can't
memorize all the terms and still keep my mind free for assimilation
thought process.

Others may not want the clutter, so you could have a button on each page
to toggle the CSS for the page.

It is just a suggestion. Would need to test it perhaps, and see how well
it is liked or disliked. I realize it may not fit into high priorities of
the WGs.

I think TBL's Semantic Web would appreciate you doing so?
Received on Saturday, 23 October 2010 13:50:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:40 UTC