fantasai | 23 Apr 10:06 2014
Picon

[css-masking] mask-box-slice: fill vs. fill-box

The spec is currently inconsistent, with 'fill' appearing in the propdef
and 'fill-box'in the description. Pick one? :)

~fantasai

fantasai | 23 Apr 10:00 2014
Picon

[css-masking] mask-composite, vocabulary, and use cases

I'm looking at

   mask-composite: clear | copy | destination | source-over | destination-over
                   | source-in | destination-in | source-out | destination-out
                   | source-atop | destination-atop | xor | lighter

and the syntax is completely arcane to me. The examples make sense.
But I'm not a graphics-library person, so I can't relate to the
vocabulary in use here.

Do we have to use Porter-Duff vocabulary, or would it be okay to use
more vernacular English for some of these terms? E.g. "source" and
"destination" mean nothing to me in terms of CSS objects, so I can't
tell what they correspond to.

Also, I'm not seeing why we have all of these things. Sure it would
be simple to implement because it's just exposing all the values in
a library, but there is a testing overhead for implementers and,
more importantly, a cognitive overhead for authors.

Specifically,

   * I see no use cases for 'clear', 'copy', or 'destination'.
     I recommend to remove them.

   * I don't understand why we need both source-* and destination-*
     variations of each operator. Shouldn't reordering be handled
     by, like, actually reordering the image list?

   # A specified compositing operator defines the compositing operation
(Continue reading)

Peter Linss | 23 Apr 04:07 2014
Picon

Agenda conf call 23-apr-2014

Time/Phone/SIP details available to WG Members in w3c-css-wg. See
https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0078.html

** CSS WG Members, please send regrets to Member-only list if you can't
** attend.

0. Extra agenda items and other digressions
-------------------------------------------

1. calc() unit algebra
----------------------
http://lists.w3.org/Archives/Public/www-style/2014Apr/0101.html

2. Grid 'subgrid' keyword
-------------------------
Decision time?

3. Percentage margins/padding on grid/flexbox
---------------------------------------------
http://lists.w3.org/Archives/Public/www-style/2014Apr/0184.html

4. Item height when max-height applied to flex container
--------------------------------------------------------
http://lists.w3.org/Archives/Public/www-style/2014Apr/0292.html

5. Box model / render tree
--------------------------
http://lists.w3.org/Archives/Public/www-style/2014Apr/0257.html

6. :role() selector
(Continue reading)

Daniel Holbert | 23 Apr 01:38 2014

[css-flexbox] New "Resolving Flexible Lengths" algorithm disagrees w/ old algorithm, when we go from negative free space to positive free space (even with flexibilities >= 1)

I ran across a case where the new "Resolving Flexible Lengths" algorithm
produces different (worse) behavior, as compared to the original
algorithm. This case has all flexibilities being >= 1, so per the "(No
change for a sum ≥ 1)" statement here...
  http://dev.w3.org/csswg/css-flexbox/#change-2012-flex-continuity
...this discrepancy is unexpected/undesirable.

The setup is fairly simple:
 - Fixed-size flex container (say, 100px wide) with 2 flex items.
 - Both items have a flex-grow & flex-shrink of 1, for simplicity.
 - First item has huge flex-basis (at least as large as container), and
a small max-main-size (say, 20px).
 - Second item has small flex-basis (say, 10px).

Live example:
  http://people.mozilla.org/~dholbert/tests/flexbox/flex-shrink-2.html

What *should* happen here (according to intuition & the old algorithm):
The first item should get clamped to its max-size, and the second item
should absorb the rest of the free space, filling up the container exactly.

What *actually* happens with the new "Resolving Flexible Lengths"
algorithm is that we *shrink* the second item, with no real need to do so.

Specifically, using step numbers from
http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths , here's
what happens:
 Steps 1 and 2: [ignoring, as they don't matter in this case]
 Step 3: We calculate free space, and get something negative.
 Step 4: We set the "originally desired free space" to something
(Continue reading)

James Craig | 22 Apr 20:24 2014
Picon

Re: [selectors4] Request for :role() selector (matches computed role using UA internals, not attribute substring matching)

Following up on this thread from last year. 

It's come to my attention that some aspects of the :role() selector will be tricky. I don't think these
negate the need for a role selector, but the CSS editors should be aware of these issues when writing this
portion of the spec. In particular, role is typically not computed when an element is not rendered. This
might cause some confusion if authors attempted to do things like using querySelectorAll() to find
unrendered elements.

For example:

    /* This will hide all native and ARIA buttons. */
    for (el of document.querySelectorAll("*:role(button)"))
        el.hidden = true; 

    /* But this will not unhide any elements, because the computed role was invalidated once the buttons became
unrendered. */
    for (el of document.querySelectorAll("*:role(button)"))
        el.hidden = false; /* No elements to unhide, b/c hidden buttons are no longer computed has having the button
role. */ 

The other potential problem may end up being an implementation detail, but it's related so I feel I should
mention it. Due to the role not being computed until an element is rendered, using role selectors for
general layout may result in rendering engines needing to execute additional rendering passes before
displaying content. It's not yet clear to me if this will cause significant performance implications. 

On Jul 3, 2013, at 1:10 PM, Tab Atkins Jr. <jackalmage <at> gmail.com> wrote:
> On Wed, Jul 3, 2013 at 1:08 PM, James Craig <jcraig <at> apple.com> wrote:
>> On Jul 3, 2013, at 12:29 PM, Tab Atkins Jr. <jackalmage <at> gmail.com> wrote:
> 
>>> What sort of things would you use this selector for?  I don't think
(Continue reading)

Tab Atkins Jr. | 22 Apr 17:25 2014
Picon

Re: [css-text] Characters per line

On Tue, Apr 22, 2014 at 2:32 AM,  <mus <at> designtoday.co.uk> wrote:
> I see, I hadnt come across that unit measurement before. I think that
> would be adequate, not sure if designers are really aware of it as they
> generally think in CPL. I have a talk next month at a London meet up, ill
> mention CH there. :)

As Zack said, using 'em' should generally be okay too.  In most fonts,
1ch is approximately equal to .5em.

~TJ

Robert Hogan | 21 Apr 22:24 2014
Picon

[css2] Margin-Collapsing and min-height


<style>
    .red{
        background: red;
        float:left;
    }

    .blue{
        background: blue;
        min-height: 60px;
    }

    h1{
        margin: 10px 0 90px;
        background: green;
        font-family: 'Garamond';
        font-size: 16px;
    }
</style>
<div class="red" data-expected-height=70><div class="blue"><h1>¡Hola!</h1></div></div>

Chrome, Safari, IE and Presto all render the red float in this test case as 90px in height. FF is alone in allowing it to get 'swallowed' by the height of the blue parent.

This is because they allow the bottom margins of h1 and its blue parent to collapse together.

http://www.w3.org/TR/CSS2/box.html#collapsing-margins says: "the bottom margin of a last in-flow child and bottom margin of its parent [adjoin] if the parent has 'auto' computed height". Since that is the case here, they collapse.

Intuitively, since min-height has the effect of creating enough space for the margin, it would not collapse with its parent's after-margin but there is no support for that elsewhere, and http://www.w3.org/TR/CSS2/visudet.html#min-max-heights explicitly rules it out:

"The following algorithm describes how the two properties influence the used value of the 'height' property:

The tentative used height is calculated (without 'min-height' and 'max-height') following the rules under "Calculating heights and margins" above.
If this tentative height is greater than 'max-height', the rules above are applied again, but this time using the value of 'max-height' as the computed value for 'height'.
If the resulting height is smaller than 'min-height', the rules above are applied again, but this time using the value of 'min-height' as the computed value for 'height'.

These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1)."

So can the behaviour be improved or should it remain as it is? Am I right in thinking the rendering in WebKit/IE/Presto is correct per the spec?


Greg Whitworth | 21 Apr 20:43 2014
Picon

[css-flexbox] What to do with an item's height when max-height is applied to the flex container

We ran into an interesting interop issue where if you set a flex container with a max-height, Firefox and IE set the flex-item height to the height of the max-content of the items, while Chrome sets the max-height of the flex-item to the suggested max-height applied to the flex-container. The spec is not completely clear on what to do in this case so I would like to reach consensus on what to do in this case:

 

A)     Have the flex items inherit their height from the flex-container’s constraints if not directly set (Chrome)

B)      Resolve their height against the largest flex-item (IE, Firefox)

 

Here is a fiddle of the repro:

 

http://jsfiddle.net/VDq6r/6/

 

Thanks,

Greg

Tab Atkins Jr. | 21 Apr 19:13 2014
Picon

[css-text] Characters per line

[Looks like Koji accidentally appended this to an unrelated thread.
I'm pulling it out, and I've trimmed the text around it to be just
Mustafa's email.]

On Apr 21, 2014, at 12:50 AM, mus <at> designtoday.co.uk wrote:
> Hello everyone
>
> I was wondering if their was anything in the CSS spec for dealing with
> Characters Per Line. Currently I've made a couple of prototypes using
> JavaScript but this can be a huge performance hit on pages with large
> amounts of text. As CPL is a huge part of read-ability for text and the
> fact we live in a responsive web world maintaining a legible character
> line is almost impossible.
>
> The general rule in typography is the CPL should be between 55-75
> depending on the typeface family and its subsequent fonts. As each font
> has a different character width this can make a huge difference. So the
> idea would be something along the lines like
>
> P {
> cpl: 75;
> }
>
> The effect would be that the paragraph of text would never go beyond this
> amount, dropping to a newline, thus maintaining readability. I thought
> about perhaps a max-cpl or min-cpl but wanted to fire you guys an email
> first to get a feel if this is something that would be reasonable.

Koji Ishii | 20 Apr 21:11 2014
Picon

Re: [css-text][css3-fonts][proposal] font-side-bearings: normal | trimmed

Requested to forward to www-style:

On Apr 21, 2014, at 12:50 AM, mus <at> designtoday.co.uk wrote:

Hi Koji

I tried emailing the w3c mailing list but it keeps throwing back errors. I
was wondering if you could forward this to the group? It was an idea i had
about Characters per line?

==

Hello everyone

I was wondering if their was anything in the CSS spec for dealing with
Characters Per Line. Currently I've made a couple of prototypes using
JavaScript but this can be a huge performance hit on pages with large
amounts of text. As CPL is a huge part of read-ability for text and the
fact we live in a responsive web world maintaining a legible character
line is almost impossible.

The general rule in typography is the CPL should be between 55-75
depending on the typeface family and its subsequent fonts. As each font
has a different character width this can make a huge difference. So the
idea would be something along the lines like

P {
cpl: 75;
}

The effect would be that the paragraph of text would never go beyond this
amount, dropping to a newline, thus maintaining readability. I thought
about perhaps a max-cpl or min-cpl but wanted to fire you guys an email
first to get a feel if this is something that would be reasonable.

Thanks for reading, apologies if this is the wrong place to suggest
something like this.

Mustafa
==

Koji Ishii | 19 Apr 22:39 2014
Picon

Re: [css-text] comments from DPub IG (Fwd)

> > 2. In section 1.3, after the example:
> > "Within this specification, the ambiguous term character is used
> > as a friendlier synonym for grapheme cluster. See Characters and
> > Properties for how to determine the Unicode properties of a
> > character."
> > "A letter for the purpose of this specification is a character
> > belonging to one of the Letter or Number general categories in
> > Unicode. [UAX44]"
> > If I replace 'character' in the second paragraph with 'grapheme
> > cluster', I am not sure I get a reasonable answer. For instance,
> > is U+0067  + U+0308 a letter? I don't think U+0308 is, does that
> > disqualify the whole cluster? Or is this a different use of the
> > term character? Does Unicode define such clusters as belonging
> > to all the groups all the code points belong to?
> 
> Ah, that's referring to some text that was recently removed from
> Writing Modes. Here's the old version:
>    
> http://www.w3.org/TR/2012/WD-css3-writing-modes-20121115/#character-properties
> 
>    #  For the purposes of CSS Writing Modes, the properties of a
>    #  grapheme cluster are given by its base character—except [...]
> 
> I'll have to restore that text, will follow-up on that with a link…

Fixed.

/koji


Gmane