[css-shapes] shape-outside and floats interaction

The current CSS Shapes spec defines how shapes interact with floats in
section 3.1 [1]. In an attempt to simplify the interaction, it states that:

---
If a float has an outside shape, its positioning is resolved as defined in
[CSS21] but the outside shape's bounding box is used in lieu of the
float's margin box.
---

This has some nice consequences (the shape never extends outside the box
used for positioning and stacking floats, and floats with outside shapes
will stack somewhat compactly with respect to their shapes). But in
practice, users have found it too limiting. Changing the float's regular
margins has no effect on where the shape is placed. And positioning the
float using the shape's bounding box has a side-effect of shifting content
inside the float relative to the shape position, which users find really
weird. 

A simple use-case that is not served by the current spec text is a left
float with content that displays in a circle with a shape-outside
corresponding to that circle, and 'margin-left:-50%'. Here the float is
positioned using the entire circle shape, but the float's contents are
shifted off to the left. Ideally, the shape would also shift to the left,
the box for positioning the float would be 50% of the float's width, and
inline content would wrap around a semicircle.

So I propose removing the sentence above, so that floats with
shape-outside are positioned and stacked exactly the same as floats with
'shape-outside:auto'. Then the regular margins (and whatever else) can be
used to position floats with shapes.

[css3-text] Editorial: CJK codepoints or CJK content language rather than CJK text

Hi,

Based on twitter discussions today, there seems to be some confusion as 
to whether the line-break property "applies to non-CJK text".

Perhaps this could be improved if the spec (especially notes) avoid the 
term "CJK text" but rather use CJK content language (linked to the 
definition) or CJK codepoints/characters.

Cheers,
--

-- 
Simon Sapin

[css3-fonts] 'font-feature-settings' and BlueGriffon

FWIW, I have just added UI for the CSS Fonts Module Level 3
property 'font-feature-settings' to BlueGriffon. This is
available if you build yourself BlueGriffon from trunk and
I will probably have nightly builds with the feature enabled
tomorrow. Builds will be available from [1].

I guess it will be an interesting playground for those of you
interested in font features. John, if you want me to implement
more features (for instance ss01 to ss20), please let me know.

[1] http://bluegriffon.org/freshmeat/nightlies/latest

</Daniel>

Github mirror: how does it work?

Hello Stylish People!

I just realized you guys have a beautiful github mirror of the dvcs
repo: https://github.com/w3c

How do you use it? What is the dark magic behind the bridge between Hg
and Git? I am asking this question because I am sort of wondering if
we WebApps peeps could do something similar. Github's reviewing and
multiple-contributor management facilities are pretty much tops.

:DG<

[css3-grid-layout] Clarification on ' span' named grid line

Hi everyone,

I couldn't find a good answer to the following case in [1]: What
happens if there is no named grid line with the given name for the
'span' case? (for example, grid-row: span 2 'nonexistent' / 5)

The specification defines what to do for the non-spanning case (ie
grid-row: 'nonexistent' / 5). It's unclear that it is supposed to
extend to the 'span' case (both examples would be equivalent to 1 /
5).

An alternative way to treat this is to make it an error and compute
the line placement to 'auto' or 'span 1'.

Any thoughts?

Thanks,
Julien

[1] http://dev.w3.org/csswg/css-grid/#line-placement

[css3-transitions][css3-animations] Proposal for animation-timing keywords for half-parabola curves - facilitating correct rise/fall/bounce type animations

The CSS transitions/animations module currently defines for the 
animation-timing and transition-timing properties, the keywords "ease", 
"ease-in", "ease-out" and "ease-in-out" as shortcuts for cubic-bezier(...) 
with certain specific arguments.

I'D LIKE TO PROPOSE that a couple more such keywords be added to this list - 
specifically, for *parabolic* timing functions:  Representing the path 
objects take either rising, or falling, under gravity.

The reason is that making objects appear to rise, fall, or bounce under 
gravity is I'd expect a fairly common use-case for CSS animation --- but 
using any of the ease-* curves to do it will result in wrong-looking 
(unphysical) behaviour:  Such animations require parabolic timing functions 
to look correct.

Rising and falling half-parabolas (*somewhat* similar in shape to ease-out 
and ease-in respectively) are also representable using cubic bezier curves, 
specifically (assuming my math is correct):

  rise:    cubic-bezier(0.33333, 0.66667, 0.66667, 1)
  fall:    cubic-bezier(0.33333, 0, 0.66667, 0.33333)

Having keyword shortcuts for these curves (perhaps "rise" and "fall"?) will 
facilitate the easy creation of physically-correct rise/fall/bounce 
animations, and will also make it clear at a glance, from looking at the 
CSS, just what such animations are supposed to do.  (Which certainly isn't 
the case if you use cubic-bezier(...) with numerical arguments instead).

Thanks for your consideration,

Agenda conf call 19-jun-2013

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. Scribe, extra agenda items and other digressions
---------------------------------------------------

1. css-text-3 Issues
--------------------
Interaction of 'text-align' and 'text-align-last':
http://lists.w3.org/Archives/Public/www-style/2013Jun/0263.html

Allowing 'letter-spacing: <length>' to justify:
http://lists.w3.org/Archives/Public/www-style/2013May/0280.html
 This would be a change for CSS2.1, which currently forbids this.

Related change: have 'normal' compute to zero, as it does for
'word-spacing' already, since with this change they would mean
the same thing.

2. CSS Ruby Editors
-------------------
https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0270.html (member only)

3. Revive direction focus nav properties
----------------------------------------
http://lists.w3.org/Archives/Public/www-style/2013Jun/0332.html

CSS overprinting

[css3-images] Helping implementers with math

Hi,

Implementing CSS gradients in WeasyPrint a few months back involved 
doing a bit of trigonometry. Refreshing stuff learned in high school 
wasn’t so bad, but there is a particular result that I found tricky to 
get and not intuitive.

This paragraph of the spec defines the gradient line for linear-gradient()

> Starting from the center of the gradient box, extend a line at the
> specified angle in both directions. The ending point is the point on
> the gradient line where a line drawn perpendicular to the gradient
> line would intersect the corner of the gradient box in the specified
> direction. The starting point is determined identically, but in the
> opposite direction.

This is a flawless definition, but it doesn’t give much clue on how to 
find that point with math and code in the general case rather than with 
pen and paper in a given case.

I was just about to use an horrible formula involving arc-tangents and 
four cases before I got this one. I’d like to add it to the spec as a 
note, hopefully helping future implementers:

     Implementation note:
     Given:

     * <var>A</var> the angle (in any quadrant) defining the gradient 
line’s direction such that 0 degrees points upwards and positive angles 
represent clockwise rotation,
     * <var>W</var> the width of the gradient box,
     * <var>H</var> the height of the gradient box,

     The distance between the center and the gradient box and the ending 
point (ie. half the size of the gradient line) is:

     <code>abs(W * sin(A)) + abs(H * cos(A))</code>

I’m confident this is correct after triple-checking my proof, but I 
could write it up if necessary.

Cheers,
--

-- 
Simon Sapin

[css-writing-modes] Should <svg> be upright in vertical writing modes?

Should <svg> be upright in vertical writing modes? In IE10 it does, in 
Chrome it doesn't.

The spec says
[[
The content of replaced elements do not rotate due to the writing mode: 
images, for example, remain upright. However replaced content involving 
text (such as MathML content or form elements) should match the replaced 
element's writing mode and line orientation if the UA supports such a 
vertical writing mode for the replaced content.
]]

I can't tell from the current spec which behavior is correct. <svg> is 
an image, but it can also involve text. A literal reading would result 
in upright if the <svg> did not involve text and not if it does, but 
that would be quite silly.

It would be good if the spec was more explicit here. Not only for <svg> 
but for other things also. "images, for example, remain upright" doesn't 
actually require anything...

--

-- 
Simon Pieters
Opera Software

[cssom-view] colorDepth/pixelDepth, match implementations or theoretical purity?

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=17522 we have a 
situation where all implementations and the spec agree on one thing, but 
that thing is wrong according to the industry standard terms. It is 
obvious that Glenn and I have different ideas about what the spec should 
say. In HTML, the policy in situations like these have almost always 
been to just match the implementations.

There can be reasonable exceptions where we would want to not match 
implementations despite interoperability, like if a security problem is 
identified or if a different definition would be vastly superior *and* 
the feature is not widely used in the Web such that changing it does not 
cause compat problems.

In the case of colorDepth and pixelDepth, the proposed change does not 
address any security problem. It would start to expose the number of 
bits in the alpha channel (also see 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14072).

The attributes can be used for fingerprinting. The proposed change does 
not change that, in fact it probably increases the fingerprinting. If we 
want to remove this fingerprinting vector, the attributes can be made to 
return a static value, probably 24. It seems at least some current 
implementations do not return a static value.

I'd like to hear from other people what they think. Do implementers want 
to change these to match the industry terms? Or remove the 
fingerprinting vector? Or leave as is?

--

-- 
Simon Pieters
Opera Software