Dirk Schulze | 28 Aug 10:59 2014
Picon

Proposal: Motions along a path in CSS

Hi,

Animating an element along a path is one of the missing parts of CSS animations today. The intention of this
mail is to get a discussion started and get a general feeling if people are interested in this kind of feature.

Animations along a path is getting asked for for quite some time and supported in SVG with <animateMotion>
(not in IE though).

## Currently there exist some libraries adding support for this kind of feature:

* YUI http://yuilibrary.com/yui/docs/anim/curve.html
* TweenJS http://www.createjs.com/Docs/TweenJS/classes/MotionGuidePlugin.html
* And a lot less common used libraries.

## Other technologies beside SVG supporting Animation along a path are:

* Adobe Flash,
* MS XAML
* and others

## The WebAnimations spec defines an JS interface to set up motion paths:

http://dev.w3.org/fxtf/web-animations/#motion-path-animation-effects

## Proposal

I would like to propose adding a declarative version for motion path that has a similar behavior as SVG’s
<animateMotion> and would be based on the underlying technique of WebAnimations.

These are the properties and the proposed values:
(Continue reading)

Gérard Talbot | 28 Aug 05:43 2014

[css-writing-modes-3] central baseline of text with 'text-orientation: upright'

Hello,

"
In vertical writing mode, the central baseline is used as the dominant 
baseline when text-orientation is mixed or upright.
"
http://www.w3.org/TR/css-writing-modes-3/#text-baselines

I do not understand how and why there can be a central baseline for text 
with 'text-orientation' set to 'upright'. How can this be?

This image

http://www.w3.org/TR/css-writing-modes-3/text-orientation-up.png

of vertical text in 2 line boxes has text-orientation set to upright.

Now, how can the baseline-alignment of glyphs be using the central 
baseline here?

Gérard

François REMY | 27 Aug 17:17 2014

[css-grid] Flexible Track Sizing & Indefinite Avail Size

Dear CSS Grid editors,

I’m trying to understand the reasons behind the choice of the sizing 
algorithm of flexible tracks under no definite size constraint. As a 
reminder, please find quoted here the algorithm in question:

# The used flex fraction is the maximum of:
#
# - Each flexible track’s base size divided by its flex factor.
#
# - The result of finding the size of an fr for each grid item
#    that crosses a flexible track, using all the grid tracks
#    that the item crosses and a space to fill of the item’s
#    max-content contribution.
#
# For each flexible track, if the product of the used flex
# fraction and the track’s flex factor is greater than the
# track’s base size, set its base size to that product.

While the reason behind the second set of constraints is obvious to me (we 
want flexible columns to at least encompass elements inside them, if we're 
free to give them any size we want), I'm not sure about the reason why the 
first set of constraints exist.

Also, if the plan is to make the layout system stable for flex factors 
approaching zero (like flexbox), then this first set of constraints will be 
annoying (as a very small flex factor can create huge track breadths (with a 
smart epsilon/epsilon-squared pair of flex factor; see test case), while a 0 
flex factor is identical to no flex at all which may result in collapsed 
columns).
(Continue reading)

Tab Atkins Jr. | 27 Aug 09:28 2014
Picon

[css-flexbox] Using "preferred size" in initial layout, rather than max-content size

In Flexbox layout step 2.E (section 9.2), we do layout on the flex
items, treating "auto" as max-content.  I think we actually want to
treat it as "preferred size".  If you've got a multicol flex item with
a specified column size and count, you want to return the product of
those properties, not the max-content size of the multicol.

This has no effect on most things, since most layout modes don't have
a preferred size, so it defaults to max-content instead.

~TJ

François REMY | 26 Aug 16:25 2014

[css-align][css-grid] IE's interpretation of stretch?

Dear CSS Align / Grid editors,
 
I’m currently wondering whether I’m currently facing a bug or a feature in IE’s behavior towards items stretched in undersized grid rows.
 
It seems that, when an element’s intrinsic height is higher than the stretchable area, IE ignores the stretch instruction. Is that part of any spec, or is this a bug?
 
[1] According to the latest CSS Align working draft, the only exception to stretch seems to be “min-height >= available size”, but IE keeps its behavior even if I set min-height to 0, so this doesn’t explain what I’m seeing.
[2] According to the latest CSS Align editor draft, stretching only applies when the items are smaller than the available size, so that would explain the visible behavior, but the fallback behavior for cases where there is no auto-sized element clearly doesn’t make sense for a content-distribution value; it also doesn’t seem to mention whether max-width/max-height have to be honored and, if they do, what should be done in the case they prevent the space to be distributed among the items.
 
So, could someone explain to me what is the current plan for the stretch value? It seems to be in flux right now, but I would like to understand where it is currently going ^_^
 
Thanks a lot,
François
 
-------------------------------------------------------------------------------
 
PS: Here’s a test case to show the issue. IE renders as the first image, and I thought it would render like the second one.
 
<!doctype html>
<html>
    <head>
        <title>Test for stretch and small elements</title>
    </head>
    <body>
        <div style="display: -ms-grid; -ms-grid-rows: 10px auto; -ms-grid-columns: 1fr">
            <input type="button" value="1" style="-ms-grid-row: 1; -ms-grid-row-span: 1; width: 50%; margin: 0px auto; margin-left: 0px" />
            <input type="button" value="2" style="-ms-grid-row: 1; -ms-grid-row-span: 2; width: 50%; margin: 0px auto; margin-right: 0px;" />
        </div>
    </body>
</html>
 
IE’s rendering:
 
Expected rendering:
François REMY | 26 Aug 16:08 2014

[css-align] Editorial: the 'stretch' definition moved, but the section titles weren't updated accordingly

NOTE: This mail is targeting the current editor draft of CSS Box Alignment, 
not its current working draft, which is fine regarding this.

In more details, my comments are:
- Section 3.1's title still mentions ‘strecth’ (yet the section doesn't 
define it)
- Section 3.3's title doesn’t mention ‘stretch’ (yet the section does define 
it)

I believe the section titles should be updated to match their content (or 
vice-versa).

Best regards,
François 

Liam R E Quin | 24 Aug 01:21 2014
Picon

Re: formatting a back-of-the-book index with CSS (no JavaScript)

On Sat, 23 Aug 2014 23:40:49 +0200
"Jan Tosovsky" <j.tosovsky <at> email.cz> wrote:

> On 2014-08-23 Liam R E Quin wrote:

> > You need the formatter to collapse ranges 
[...]
> I hope this collapsing will be optional.
Yes.

> I distinguish (but who else cares?):
> primary 9-10  (the term is discussed thoroughly within this range)
> primary 9, 10 (there are individual occurrences on every particular page)
Yes, there's a property to let you intermix these treatments.

> I also expect those directly specified ranges ending up as 10-10 merged just
> into 10.
I think I forgot to mention that explicitly, although it's in XSL-FO.

> 
> > I wrote a short blog entry on this:
> > http://barefootliam.blogspot.ca/2014/08/back-of-book-indexes-and-
> > css.html
> 
> A nice overview. 
> 
> I'd like to add a note to column balancing. When it is employed, there is
> another constraint to cope with to meet all typographic rules:
> (1) Page register (the last line should be placed at the same position on
> every page) 
> (2) Orphan/Widow (no single line should be located at the end/top of the
> page)
> (3) Balanced columns

Yes, I agree - but these are not special to formatting of an index, so I didn't get into it here.

> When e.g. the first column ends with the letter followed with the first
> entry (primary):
> - should this block be overflown to the next column? Should the next column
> be balanced? If so, this page won't meet the page register.
Copy-fitting is another problem, and again I agree it's important and particularly obvious in an index.
I'm trying to focus on only one aspect because I think it's easier to persuade people to make a small change,
and because the small change is the only part specific to an index; more work on keep-together,
keep-with-next, column balancing and "try to make this content fit this space" (copy fitting) will have
to follow and I hope you'll help us make it work :-)

[...]

> I am not so optimistic about the automatic sorting. E.g. Czech rules define
> different sort order for the first and the second letter.

Neither am I - but my proposal is only for formatting. Sorting the index could be done with XSLT, or with
people who prefer a procedural approach, python or JavaScript, and yes, using surrogate keys (sort-as)
where needed.

Probably I should add a complete worked example to my blog, so people can get a clearer idea of what I'm trying
to propose, so that they can shoot it down more easily :-)  Thanks for your comments.

Liam

--

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Liam R E Quin | 23 Aug 21:04 2014
Picon

formatting a back-of-the-book index with CSS (no JavaScript)

I'm slowly wrking through things people currently do with XSL-FO, trying to make sure they're possible
with pure HTML + CSS.

You can format an index for the back of a book using HTML easily enough, and "a" elements, but you run into a
snag when you try and format the index into (say) PDF, or even for screen-based paged media.

An index will typically have entries like
   Boats, canal 17, 19-25, 38
You need the formatter to collapse ranges like 19-25 based on when items appeared on consecutive pages, and
also for the formatter to remove duplicate numbers if two items appear on the same page after formatting.

I wrote a short blog entry on this:
http://barefootliam.blogspot.ca/2014/08/back-of-book-indexes-and-css.html

Right now people seem to be either using JavaScript in PrinceXML, or post-procesing the area tree or the PDF
with AntennaHouse, or using extension properties.

There are still a couple of minor issues - e.g. the best way to specify the comma and dash to be inserted.

Note, I'm only talking about formatting an index, not building one. Like a table of contents, right now the
markup has to be in the document - how to get it there is a separate topic.

Thanks,

Liam

--

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Florian Rivoal | 21 Aug 23:04 2014
Picon

[css-images][selectors][css21] ::before and ::after on replaced elements

According to the discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=169334 and to how all
(modern) implementations behave, ::before and ::after don't work on
replaced content, such as images, making the following code a no-op:

 <at> document domain("xkcd.com") {
     <at> media (hover:none) {
     #comic img::after { content: attr(title); }
    }
}

However, I can't seem to find which spec says this. The best I can find is
CSS2.1, section 12.1:

    "This specification does not fully define the interaction of
     :before and :after with replaced elements (such as IMG in HTML). This
     will be defined in more detail in a future specification."

However, this is merely saying that how it works in unspecified, not that
it is specified not to work.

Selectors point back to 2.1, while Image Values and Replaced Content are
silent on this topic.

If we're happy with this behavior, it should probably be specified
somewhere.

Alternatively, if we want to let me add the snippet above to my user style
sheet on my phone, we need to say how it works :)

  - Florian

Andrew Cunningham | 21 Aug 13:51 2014
Picon

Re: [css-fonts] new generic font 'emoji'


On 21/08/2014 6:00 PM, "John Daggett" <jdaggett <at> mozilla.com> wrote:
>

>
> Part of the motivation here is that when Unicode defined a mapping
> of emoji characters into Unicode, it explicitly unified some of
> these with existing symbol codepoints. If an author relies on system
> font fallback to choose a font there's no guarantee an emoji font
> will be prioritized over a symbol font, since it's difficult for a
> user agent to distinguish between symbol vs. emoji usage. Specifying
> the 'emoji' value in a fontlist would prioritize the use of color
> glyphs for all codepoints covered by the emoji font.
>

How does this differ from fallback for any other Unicode block?

The reality is that its pot luck whether font fallback chooses an appropriate font, this isn't unique for Emoji.

And rather than shoe horning emo

> Thoughts?
>
> Cheers,
>
> John Daggett
> Mozilla Japan
>
> [1] http://www.w3.org/TR/css3-fonts/#generic-font-families
>

emoJi

Florian Rivoal | 21 Aug 12:16 2014
Picon

[css-color] Editorial - Named colors

http://dev.w3.org/csswg/css-color/#named-colors says this:
  16 of CSS’s named colors come from HTML originally: [...]. Nearly all of  
the
  rest (save two special values, transparent and currentcolor) come from one
  version of the X11 color system, used in Unix-derived systems to specify
  colors for the console.

There is one value which is neither coming from HTML, nor an X11 color,  
nor one of the 2 special values: rebeccapurple

I suggest amending the text to:
  [...] ((save two special values, transparent and currentcolor, and one  
memorial value, rebeccapurple) [...]

Alternatively, if we don't want to single out rebeccapurple, the following  
phrasing makes the list of exceptions non exhaustive:
  [...] ((two special values are transparent and currentcolor) [...]

  - Florian Rivoal


Gmane