Lea Verou | 24 Jul 21:43 2014

[css3-ui] Does `resize` apply to generated content?

I tested the `resize` property on various browsers today and the results were buggy everywhere [1]. WebKit/Blink shows a resize handler which does nothing, and Gecko is even weirder, showing a resize handler on the pseudo-element, that resizes the parent!

I posted about this on twitter, and some authors were not even sure whether the property should apply to generated content [2][3]. css3-ui states it should apply to “elements with ‘overflow’ other than visible” in the propdef table [4]. Does this include pseudo-elements? Is there an editorial issue here?


Lea Verou  http://lea.verou.me   <at> leaverou







Tab Atkins Jr. | 24 Jul 01:58 2014
Picon

Re: [css-color-4] Renaming gray()

On Wed, Jul 23, 2014 at 4:11 PM, Jan Tosovsky <j.tosovsky <at> email.cz> wrote:
> On 2014-07-23 Lea Verou wrote:
>> The gray() functional notation [1] is a great idea for specifying
>> desaturated colors with varying degrees of transparency in a concise
>> and
>> readable way. However, I’m not sure about the naming. Right now, the
>> named color `gray` corresponds to gray(50%). gray(0%) is black and
>> gray(100%) is white.
>
> Some XSL-FO formatters use 'grayscale' psedo profile for this:
> http://mediawiki.renderx.com/index.php/XEP_User_Guide/Appendix_A_XSL-FO_Conformance#Color_Specifiers
>
> But I take it rather as a syntactic sugar for CMYK: 0,0,0,blac(K).
>
> However, if I understand correctly, CSS gray is sRGB based and hence potentially problematic for
printing when transformed to device profiles.
>
> I like the approach of pseudo Gray/CMYK profiles as they allow me defining exact values which are
preserved (in the PDF output) without profile conversions. So when I define gray, it is printed as shade of
black instead of RGB composition.

Some day we'll have the ability to define/reference color profiles,
and you'll be able to use a cmyk() function properly.  Until then,
device-cmyk() exists, which automatically uses the output device's
color profile (if the UA knows it), and otherwise uses the ugly naive
conversion to RGB.

> Btw, as non native speaker I am very often confused by grey/gray mess and it is unclear which one to use ;-)

American English uses "gray", British English uses "grey".  CSS
generally uses American English to define its names.

> Would 'lightness' be misleading here?

That seems to indicate a quality of some color, rather than a color by itself.

~TJ

Håkon Wium Lie | 24 Jul 00:51 2014
Picon

[css-figures][css-multicol][css-overflow] Ten CSS One-Liners to Replace Native Apps

I've written a piece on how CSS can reproduce functionality currently
used in native apps. 

  http://alistapart.com/blog/post/ten-css-one-liners-to-replace-native-apps

The sample code is from CSS Figures and CSS Multicol, with a dash of
CSS Overflow:

  http://figures.spec.whatwg.org/
  http://www.w3.org/TR/css3-multicol/
  http://dev.w3.org/csswg/css-overflow-3/#overflow-properties

Pages and columns have been basic building blocks in typography since
the Romans started cutting scrolls into pages. This is not why
browsers should support them. We should do so because they help us
make better, more beautiful, user experiences on mobile devices.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome

Tab Atkins Jr. | 24 Jul 00:35 2014
Picon

Re: transform-snap propery

On Thu, Jun 19, 2014 at 9:37 PM, Tim Severien <timseverien <at> gmail.com> wrote:
> Hi CSS working group,
>
> I'd like to propose a new CSS property; transform-snap.
>
> I use the transform property frequently for experiments and practical
> solutions as well. A common approach to vertical align an element is to set
> a top offset of 50%, then translate -50%. This often causes pixel
> misalignment in Webkit. Text becomes much harder to read. But Gecko handles
> this nicely.
>
> The inconcistency of implementation has left me wanting for a solution.
> There are three:
>
> - The spec is refined to make all implementations act the same
> - A property is introduced to toggle pixel snapping for translates
> - A property is introduced to define all kinds of snapping

Or a fourth - make vertical centering possible without hacks.  This is
luckily possible today - just use flexbox and align-content:center;.
(This is technically still *very slightly* hacky if you're not using
Flexbox for anything else, but the Alignment spec isn't yet finished
and implemented. When it is, you can use align-content and
justify-content on display:block elements too.)

> That last option seems most of interest to me. Not only can you use it
> prevent subpixels, you can also apply it to the other functios, like
> rotation whilst keeping the syntax familiar.
>
> A few examples:
> /* prevent subpixels by forcing it in a 1x1 pixel grid */
> transform-snap: translate(1px, 1px);

If the following example is at all representative, you really don't
want to do that:

<!DOCTYPE html>
<div class=one>foo</div>
<div class=two>foo</div>
<style>
div { animation: foo 3s linear alternate infinite; }
.one { animation-name: continuous; }
.two { animation-name: discrete; }
 <at> keyframes continuous {
 from {
  transform: translateX(0); }
 to {
  transform: translateX(100px); } }
 <at> keyframes discrete {
 from {
  transform: translateX(0);
  animation-timing-function: steps(100); }
 to {
  transform: translateX(100px); } }
</style>

At least in Chrome, the second element is noticeably jerky.

> /* snap rotation */
> transform-snap: rotate(45deg);

I can maybe see the use of this, for example if you wanted to animate
clock hands that only tick at 1/60th intervals of the circle, you'd
set the snap to be 6deg.  Then you could set values and let
transitions/animations just work normally, without having to worry
about setting up step() timing functions appropriately.

Any other use-cases?

~TJ

Dave Cramer | 24 Jul 00:23 2014
Picon

[css-gcpm] Footnotes as Regions

During the Seoul F2F, we discussed the idea of implementing footnotes (and running heads) using regions [1], in order to reduce the amount of "magic" required to define footnotes. The basic idea is that we have document content that needs to move somewhere else. So it seems quite natural to write

span.footnote {
  flow-into: footnote;
}

and then have a "footnote" region at the bottom of the page. Defining that region could happen in several ways. GCPM currently uses an <at> footnote area inside <at> page, and we could just use that along with "flow-from" rather than "float: footnote":

<at> page {
  <at> footnote { flow-from: footnote }
}
 
We could also adopt some box-creation mechanism such as CSS Pagination Templates [2], and use those in the page context:

<at> page {
  <at> slot footnote { flow-from: footnote }
}
 
This would allow us to have multiple footnote areas, which is more common than you think:

<at> page {
  <at> slot footnote1 { flow-from: footnote1 }
  <at> slot footnote2 { flow-from: footnote2 }
}

The pagination templates spec also has a "required-flow" property, which could perhaps be at the slot level rather than the template level to say "don't create this slot unless there's a footnote on the page."

<at> page {
  <at> slot footnote {
    flow-from: footnote;
    required-flow: footnote;
    height: auto;
  }
}

This region could also be an exclusion, so that it carves the necessary space from the main text area on a page. But there are still lots of issues to deal with.

A. We need a reference to the footnote's original location, before it was removed from the flow, so we can insert a reference mark. GCPM has a ::footnote-call pseudo-element, but in Seoul there was some talk of a general-purpose solution. Right now the book.js folks use three nested spans for footnotes, which is a burden for document authors. So if span.footnote was moved to a region, we'd leave behind

span.footnote::place-holder {
  content: counter(footnote);
  font-variant-position: super;
}

Of course, much bikeshedding would be required. This idea would potentially be useful for figures, side notes, and any other content that was floated or moved to a region.

B. We need to express the constraint that the footnote appear on the same page as its reference, and how to handle footnotes (or portions of footnotes) that won't fit on the original page. This is where the serious magic happens.

C. The interaction between footnotes and columns is complex. In particular, how would you specify that a footnote be displayed at the bottom of the column that contains the reference?

D. Footnotes are sometimes displayed inline to save space. The document author could easily do this by setting the display value on the footnote, but in some cases we'd like the user agent to set short footnotes inline, and longer footnotes as blocks.

span.footnote {
flow-into: footnote;
bikeshed-display: compact;
}

I'm starting to write all this up for GCPM level 4, but would very much appreciate any thoughts.

fantasai | 24 Jul 00:14 2014
Picon

Re: [css3-background] PFWG input on focus ring

On 07/23/2014 06:26 PM, Antony Kennedy wrote:
>
>> A user can disable such modifications by restricting it via !important
>> rules in the user style sheet (or an equivalent UI control) just like
>> disabling author-specified colors and fonts.
>
> A user can set their own outline with !important, but out of interest,
> is there a way for them to stop the author overriding browser defaults?

Yes. From CSS’s perspective, the browser defaults are represented
in the cascade as user-level style rules. So making those rules
!important (or in any case having them enter the cascade at the
user !important level) will "stop the author overriding browser
defaults".

This is how we represent all such preferences, such as default
colors and fonts.

~fantasai

Tab Atkins Jr. | 23 Jul 23:05 2014
Picon

Re: [mediaqueries] two syntax items

On Wed, Jul 23, 2014 at 11:57 AM, Winston <wbe <at> psr.com> wrote:
> Yes, I do think this one's useful.  The problem is that the definition
> of <general-enclosed> (which is somewhat broken, but I'll get to that
> next) suggests that "" (the empty string) does not qualify.  After
> reading both level 4 draft and level 3, I was unable to determine
> whether there was intent for "" to be treated as a valid
> <general-enclosed> expression, prompting my original email.  I contend
> the spec needs to say, either via the rule or via an example.

Sorry, this is a little unclear - do you mean literally an empty
string, or just "nothing between the parentheses"?  It's sometimes
hard to tell whether quotes are meant to be delimiters for a code
string or part of the code itself. ^_^

In any case, both an empty string and nothing are valid, as they both
match <any-value>*.

> 2) On to the definition of <general-enclosed> itself...  This definition
>    in the June 3 version of the Level 4 Draft:
>
>    ----------
>
>    <general-enclosed> = [ <function-token> | ( ] <any-value>* )
>
>    ----------
>
>    looks broken.  I read it as "[...] <any-value>* )" (requiring a close
>    paren even if there was no open paren).

What do you mean "even if there was no open paren"?  It's possible
that you're misinterpreting <function-token>, which is understandable,
since it's a slightly funky detail of CSS's tokenization.
<function-token> is the "beginning" of a function, composed of the
name and open paren.

> It also [as of June 3] means
>    that "" is not a valid <general-enclosed> (and thus that "()" is a
>    syntax error).

Correct that neither an empty string nor nothing at all are valid
<general-enclosed> values - as the name suggests, they must be
enclosed, by parentheses in this case.  However, `()` is absolutely
valid.  What makes you think otherwise?

> 3) At high level, while I understand why "()" has been defined to return
>    false, that's contrary to what a newcomer might expect.  One might
>    think "()" -- an expression in which no restrictions appear -- ought to
>    evaluate to the same value as "" (i.e., true), just as the absence of
>    an expression in " <at> media {...}" does, and that not() would be false,
>    and that "( <general-enclosed> )" would be the other way around (as it
>    is officially) only if there's non-whitespace content.  That could be
>    accomplished by changing the first part of <media-in-parens> to
>    something like:
>
>    <media-in-parens> = ( [ whitespace* | <media-condition> ] ) |  ...
>
>    and leaving <general-enclosed> as not including "".  Of couse, then
>    the spec would need to add that "(whitespace*)" evaluates to true,
>    and the example I suggested back in topic #1 above would have to be
>    reversed.  :)
>
>    Not a bug, just an observation.  :-)

() is false not because it's empty, per se, but because it's a syntax
error that we allow for future-compatibility reasons.  Newcomers
shouldn't use it at all.

>    Of course, the other, even simpler alternative, is simply to declare
>    "(whitespace*)" a syntax error, since it doesn't really provide much
>    value.  The previous idea of having it be true was just if you wanted
>    to keep "()" as syntactically valid.

While it's possible to do so, I don't see much reason to make it
actually a syntax error, given the general MQ theme of attempting to
recover from errors.

~TJ

Tab Atkins Jr. | 23 Jul 20:56 2014
Picon

Re: [css-flexbox] feedback - issue with responsive columns and white-space: nowrap, using flex-shrink: 0 and flex-wrap: wrap

[please don't top-post: http://wiki.csswg.org/tools/www-style]

On Wed, Jul 23, 2014 at 11:14 AM, Richard Dodd <richard.o.dodd <at> gmail.com> wrote:
> Hi
>
> I've updated the example to make the paragraph smaller
> (http://jsfiddle.net/W7g3U/4/). The use case I'm looking at is using flexbox
> to automatically stack the columns when there isn't enough space for them
> both. This works fine, but then I want the text to wrap once all the space
> has been used up. Maybe this use case isn't possible with flexbox.
>
> Here is an example using javascript to achieve the result
> http://plnkr.co/edit/Ppoe8xJrrbC16Y1vyWCD (it's not very neat, but enough to
> get the idea. Try making the width of the preview smaller)

Okay, so you want the columns to get as small as possible to fit on a
line (flexing out to fill the line if there's leftover space), and
then their contents should wrap as well.

This is easy to achieve - you need to tell the flex items to start at
the *minimum* size (taking nowrap into account), and then grow as
necessary.  Do something like this:

.column {
    flex: auto;
    width: min-content;
}

(min-content needs prefixes right now in Firefox and Webkit/Blink, so
you'll need to write "width: -wekbit-min-content; width:
-moz-min-content;".)

You *should* be able to just move the min-content keyword up into
'flex', but that's not currently supported in Chrome, at least (which
is a bug).  The above code does the same thing, since "flex: auto"
defers to the width/height property.

If you also want to enforce some reasonable minimum size (for example,
preventing a column from being less than 10em wide, even if the nowrap
parts are narrower than that), throw in a min-width as well.

~TJ

Tab Atkins Jr. | 23 Jul 20:04 2014
Picon

Re: [css-device-adapt] Target node for application of the style properties

[sorry for the delay; our moderation queue was just cleared]

On Wed, Jun 4, 2014 at 6:02 AM, Dylan Barrell <dylan.barrell <at> deque.com> wrote:
> I have read through the draft at http://dev.w3.org/csswg/css-device-adapt/
> and I cannot find any specification of which HTML node the style properties
> will be applied against or how they can be read and set from JavaScript.
>
> Is this content still pending?

The properties in a  <at> viewport rule don't apply to any element, they
apply to the viewport itself.

They can be read from JS using the normal CSSOM methods - get the
stylesheet object, iterate the rules until you find the  <at> viewport one,
then get its .style property.  This isn't particularly convenient (the
CSSOM isn't very well-designed), but it'll do.

~TJ

Lea Verou | 23 Jul 20:01 2014

[css-color-4] Renaming gray()

The gray() functional notation [1] is a great idea for specifying desaturated colors with varying degrees of transparency in a concise and readable way. However, I’m not sure about the naming. Right now, the named color `gray` corresponds to gray(50%). gray(0%) is black and gray(100%) is white. 

After using this function myself for a while (through emulating it in SASS), I’m starting to think its naming is quite unintuitive. The usual assumption with functions that take a 0-100% parameter is that 100% gives the full “effect” of the function name, in this case, gray. Ask any random person what color they think gray(100%) represents, I doubt they’d guess white. I just tried it with a friend and his response verified what I thought.
For example, think of CSS filter functions: sepia(100%) colorizes the image as sepia, values < 100% are a lighter version of the effect. Same with invert(), grayscale() etc. 

If we want to keep the link to hsl(), white() might be a better name. Although, I’m not sure if white(0%) == black is exactly intuitive, but it seems more intuitive than gray(0%).
Or, we might reverse the parameter and have black(100%) == black and black(0%) == white, which is on par with how many real life things work, such as (grayscale) printing.
Or maybe someone else has a better idea?


Lea Verou  http://lea.verou.me   <at> leaverou







Tab Atkins Jr. | 23 Jul 20:01 2014
Picon

Re: [css-flexbox] feedback - issue with responsive columns and white-space: nowrap, using flex-shrink: 0 and flex-wrap: wrap

[Sorry for the delay; our moderation queue was just emptied.]

On Mon, Jun 2, 2014 at 1:58 PM, Richard Dodd <richard.o.dodd <at> gmail.com> wrote:
> Hello
>
> It seems that white-space: nowrap is ignored when used in a div with
> flex-shrink: 0 in a flex-wrap: wrap container (with display: flex). Example
> here: http://jsfiddle.net/W7g3U/1/. Does the spec allow for precedence to be
> given to wrapping (I want the whitespace to wrap before the flexbox, but
> then the flexbox to wrap if the text with white-space: nowrap).
>
> Could someone point me to the relavent part of the specification? Can I
> achieve what I am aiming to?

I'm not sure I understand your example, or at least the connection
between it and your description.  All of the "nowrap" things are, as
desired, not wrapping.  It seems like the problem you're running into
is with the *wrapping* element not wrapping, and instead just being
really big, right?

If so, this is because flexbox treats auto-size children as
max-content (see substep E of
<http://dev.w3.org/csswg/css-flexbox/#algo-main-item>) when initially
figuring out their size.  Long paragraphs thus get *really wide*,
because they contain a lot of text that all gets put on the same line.
Normally the auto-shrinking behavior takes care of this and brings the
flex item back down to a reasonable size, but in your case you've
explicitly set the item to not shrink.

You can get around this by either leaving the flex-shrink alone (so it
sticks with its initial value of 1), or by setting an explicit width
of some kind on the flex item (in your example, the .column element).
The former should work fine - just swap your "flex: 0 0 auto;" with
"flex: auto;".  This'll wrap your paragraph, but the nowrap things
will still be nowrap, as you requested.

Of course, for any decent-length paragraph, this'll still make the
flex item as wide as the container, so that it always takes up a whole
flex line by itself.  If this isn't what you want (maybe you want the
paragraphs to wrap normally, but not get *too* wide either), just set
a max-width on the paragraph or the flex item.

~TJ


Gmane