Cameron McCormack | 28 Mar 06:46 2015
Picon

[css-font-loading] using inherit in FontFaceSet.{load,check} font argument

The spec should say what it means to use “inherit” (and other CSS-wide
keywords) in the first argument to the load() and check() methods on
FontFaceSet.  Throwing an exception sounds good.

--

-- 
Cameron McCormack ≝ http://mcc.id.au/

Christian Biesinger | 27 Mar 23:08 2015
Picon

[css-flexbox] abspos & align-self: stretch

Hi there,

I'm working on implementing the new abspos behavior, as described in
http://dev.w3.org/csswg/css-flexbox/#change-2012-static-pos and
http://dev.w3.org/csswg/css-flexbox/#abspos-items

I just wanted to verify what the expected behavior of align-self:
stretch on an absolutely positioned item is. Should it be converted to
flex-start or should the abspos item be stretched? I assume the
former?

thanks!
-christian

John Daggett | 27 Mar 07:53 2015

[css-font-loading] loading fonts and changes in status


There are a couple places in the Font Loading spec where the behavior of
implementations doesn't match what the spec defines for precisely when
changes to the status field of FontFace objects occur.

In Section 2.1, when a binary blob is used to create a FontFace object,
the initial state of the object is implied to be "unloaded". The spec
states:

  If font face’s [[Data]] slot is not null, queue a task to set
  font face’s status attribute to "loading".

This implies:

  var f1 = new FontFace("test", fontDataBlob);
  assert(f1.status == "unloaded");

Yet the Chrome implementation starts loading the data immediately, so
for font blob FontFace objects, the status attribute is *never* unloaded:

  var f1 = new FontFace("test", fontDataBlob);
  assert(f1.status != "unloaded");

Similarly, in section 2.2 where the load() algorithm is defined, step
(3) indicates that after a call to load() the status is always "loading":

  3. Otherwise, set font face’s status attribute to "loading",
     return font face’s [[FontStatusPromise]], and continue
     executing the rest of this algorithm asynchronously.

This implies:

  var f2 = new FontFace("test", "local(Georgia)");
  f2.load();
  assert(f2.status == "loading");

Here too Chrome may decide to trivially load the font such that the
status after the load() call is "loaded" instead.

In both these cases I think the implementation behavior of Chrome and
Gecko is better than what the spec currently specifies. I think we
should update the spec to allow implementations to immediately switch
the status to loaded/error if that's a trivial task that doesn't need to
run asynchronously.

Regards,

John Daggett


Daniel Holbert | 27 Mar 07:33 2015

[css-flexbox] incorrectly-linkified "flex basis" in spec (wants to be "flex-basis", which will probably fix linkification)

Easy flexbox spec typo-fix, I think:

The "flex-basis" property definition's section on <‘width’> has 2
mentions of "flex basis" (un-hyphenated), followed by 2 mentions of
"flex-basis" (hyphenated).

I think all of these instances are referring to the "flex-basis"
property, so they should all be hyphenated and link to the
property-definition.  (The unhyphenated ones currently link to a
completely different chunk of the spec, which explains the concept of a
flex basis.)

Spec quote:
  # auto
  #  When specified on a flex item, the auto keyword
  #  retrieves the value of the main size property as
  #  the used flex basis.
(Needs hyphen)----^

  # <‘width’>
  #  For all other values, flex basis is resolved
(Needs hyphen)-----------------^
  #  the same way as width in horizontal writing
  #  modes [CSS21]: percentage values of flex-basis
  #  are resolved [...] Similarly, flex-basis [...]

Link:
http://dev.w3.org/csswg/css-flexbox-1/#propdef-flex-basis

~Daniel

John Daggett | 27 Mar 03:35 2015

[css-font-loading] family name parsing note


I think it might be a good idea to add a note about the parsing of font
family names in Section 2.1. The spec currently defines the parsing of
the family argument to the FontFace constructor as:

  Parse the family argument, and the members of the descriptors
  argument, according to the grammars of the corresponding
  descriptors of the CSS <at> font-face rule.

This is fine I think but the current Chrome implementation treats the
family argument as if it was already quoted, such that the assertion
below will fail:

  var f1 = new FontFace(" <at> blah", "url(x)");
  assert(f1.status == "error"); // <at> blah is not a valid name unless quoted

Suggested note:

As with font family names within <at> font-face rules, the family argument
is a single font family name. It can be unquoted or quoted and it cannot
be a generic font family name (e.g. sans-serif).

Test examples:

  var f2 = new FontFace("'simple'", "local(Georgia)");
  assert(f2.status == "unloaded");

  document.fonts.add(f2);
  document.fonts.load("simple");
  assert(f2.status != "unloaded"); // simple == 'simple' so f2 should be loading

Regards,

John Daggett

Tab Atkins Jr. | 26 Mar 23:26 2015
Picon

Re: [css-transforms] Specifying different transitions properties for different transform functions

On Thu, Mar 19, 2015 at 3:14 PM, Zacqary Adam Xeper
<zxeper <at> fastcompany.com> wrote:
> Hi everyone. I've run into a problem working with CSS transitions on the
> transform property: I'd like to specify a different transition-duration and
> transition-timing-function for transform: scale() and transform:
> translate(). Unfortunately, the only thing I'm allowed to do is:
>
> transition: transform 0.5s;
>
> What I'd like to be able to do is something like:
>
> transition: scale 0.5s, translate 0.3s;
>
> Obviously that's not the best syntax for it, given that scale and translate
> are functions, not properties. But I haven't seen this discussed and I think
> it's worth looking into. I'd like to be able to have this kind of control
> with a standard library instead of having to render to <canvas> or
> something.

If the group accepts my proposal for transform/rotate/scale to be
properties (like perspective and motion-path are), then you'll be able
to transition those three independently, as long as you're using them.
(That is, it won't help you with random translate() functions inside
of transform; it'll let you transition the 'translate' property,
specifically.)

~TJ

Kenneth Moore | 26 Mar 21:45 2015

[css-flexbox] Discussing the Addition of a '::flex-line' pseudo-element

Good Afternoon,

 

I believe that flexbox specification is omitting a very useful feature, as it does not include the ability to target ‘flex-lines’ within a multiline flex container (from a CSS rule).

 

To accomplish this the flexbox spec could include a new flex-line pseudo-element. I imagine the implementation would be similar to the pattern used by the ‘first-line’ pseudo-element. But, a flex-line pseudo-element would have to target each flex-line, not just the first.

 

For Example:

·         .flex-container::flex-line

­   Selects each flex-line within a flex container

·         .flex-container::flex-line > .flex-item:first-child

­   Selects the first flex-item of each flex-line

·         .flex-container::flex-line > .flex-item:last-child

­   Selects the last flex-item of each flex-line

 

It could also work with other pseudo-selectors for added utility:

·         .flex-container::flex-line:nth-child(even)

­   Selects even flex-lines

·         .flex-container::flex-line:not(:first-child)

­   Selects every flex-line except the first

 

Flex-box spec claims that it that ‘flex lines are hypothetical containers used for grouping and alignment by the layout algorithm’. It kind of makes sense that a hypothetical container would be a pseudo-element. 

 

This would be very useful in situations where you are applying a border and border-radius to a series flex items that could wrap. There are many design patterns that make use of “:first-child” and “:last-child” to prevent borders from stacking and to set an appropriate border-radius on edge elements. These design patterns even apply to flex based layouts. Since flexbox solves so many CSS layout issues I figure It could also solve something that is nearly impossible to do as of now. Is this a feature worth consideration?

 

Kenneth Moore

User Experience Designer

Ungerboeck Software International

Kenneth.Moore <at> Ungerboeck.com

 

Mats Palmgren | 26 Mar 19:26 2015

[css-grid] Editorial: the location of chapter 4.3

This is the structure chapter 4:
4. Grid Items
     4.1 Collapsed Grid Items: the visibility property
     4.2 Reordered Grid Items: the order property
     4.3 Static Position of Grid Container Children
     4.4 Z-axis Ordering: the z-index property

I think 4.3 doesn't belong there because it's not about
grid items like the rest is.  It's about grid container
child elements that are absolutely positioned, which we
have now established else-thread are not grid items.

It should probably be merged into 9.4 or moved to
a sub-chapter 9.4.x instead.

Thanks,
Mats

Shane Stephens | 26 Mar 18:48 2015
Picon

[motion-path] Request for FPWD

Hi www-style,

In Sydney, the SVGWG resolved that we could publish the motion path specification as a FPWD, pending approval from the CSSWG.

Can haz approval?

Thanks,
    -Shane
Zacqary Adam Xeper | 19 Mar 23:14 2015

[css-transforms] Specifying different transitions properties for different transform functions

Hi everyone. I've run into a problem working with CSS transitions on the transform property: I'd like to specify a different transition-duration and transition-timing-function for transform: scale() and transform: translate(). Unfortunately, the only thing I'm allowed to do is:

transition: transform 0.5s;

What I'd like to be able to do is something like:

transition: scale 0.5s, translate 0.3s;

Obviously that's not the best syntax for it, given that scale and translate are functions, not properties. But I haven't seen this discussed and I think it's worth looking into. I'd like to be able to have this kind of control with a standard library instead of having to render to <canvas> or something.

Zacqary Adam Xeper
Web Developer, Fast Company
7 World Trade Center
New York, NY 10007
212-389-5546
Mats Palmgren | 26 Mar 17:11 2015

[css-grid] Comments about grid item 'display' value and the term "grid-level boxes"

Hi,

I have two comments on the following text from "4. Grid Items":
"A grid item establishes a new formatting context for its contents.
The type of this formatting context is determined by its display
value, as usual. The computed display of a grid item is determined
by applying the table in CSS 2.1 Chapter 9.7. However, grid items
are grid-level boxes, not block-level boxes: they participate in
their container's grid formatting context, not in a block
formatting context."
http://dev.w3.org/csswg/css-grid/#grid-items

1. It omits that a grid item's 'display' value is blockified.
    Please add the equivalent of this text from Flexbox:

http://dev.w3.org/csswg/css-flexbox-1/#flex-items
"The display value of a flex item is blockified: if the specified
display of an in-flow child of an element generating a flex
container is an inline-level value, it computes to its block-level
equivalent. (See CSS2.1§9.7 [CSS21] and CSS Display [CSS3-DISPLAY]
for details on this type of display value conversion.)"

2. I searched the spec text for "grid-level box" to try to find
    its definition but this is the only occurrence.  This is when
    I realized that the last sentence above *is* the definition of
    "grid-level box", i.e. a box that participate in their
    container's grid formatting context.  I found this a bit
    confusing and would like you to consider reformulating that
    last sentence to make it clear that it's defining the term
    "grid-level box" there, rather than just mentioning a detail
    about them in passing.

Thanks,
Mats


Gmane