Florian Rivoal | 4 Mar 16:29 2015

Re: [mediaqueries] additional types of media features

On 24 Feb 2015, at 11:08, christoph142 <at> gmx.com wrote:

I withdraw my request.

I forgot about the existence of view-mode media feature.
This caters for both use cases (windowed/floating for embedded and minimized for previews).
“minimized” is supposed to be used for “dynamic graphical representation being available” though. Not sure if this is 100% correct to use for static previews then. I’ll leave this decision up to you.


Sorry for the slow answer.

I agree that ''view-mode: minimized'' should cover what you expected for the preview use case.

To distinguish between static previews and dynamic ones, you may do something like this:

<at> media (viewmode: minimized) and (update-frequency: none) {...}

I agree that the view-mode text is not ideally phrased, but I take "dynamic" to mean dependent on the content, rather than animated, so that still works out.

The embedded feature request originates from this discussion: https://code.google.com/p/chromium/issues/detail?id=459959 (see comment #1, too).

For the emebdeed use case, "view-mode: floating" is not expected to match for iframes and the like, but given the use case described in the bug quoted above, it would indeed be appropriate there.

 - Florian
Florian Rivoal | 4 Mar 15:16 2015

[css-ui] review of the latest batch of edits and suggested tweaks

Hi Tantek,

Thanks for the latest edits, the spec is in pretty good shape, with almost all issues resolved now.

I've made a quick review of your commit, and here are my comments:

=== resize property ===
See this mail:

=== text-overflow ===

> Note: The "[...] its block container element" detail of the "clip" value definition is at risk pending
implementation and potentially web compatibility feedback.

I don't think the note and the "at risk" are needed, since that is the legacy behavior that everybody
implements since forever (including browsers that don't support the text-overflow property, since
''clip'' is the default value).

=== cursor ===

> The cursor property does not apply over native user-agent controls such as scrollbars, resizers, or
other native UI widgets e.g. those that may be used inside some user agent specific implementations of
form elements.

I'd go with "UAs may ignore the cursor property" rather than "The cursor property does not apply". We want to
allow UAs to display whatever cursor they deem appropriate over these controls, but there is no need to
forbid them from paying attention to the cursor property if they don't have any particular cursor they
want to display.

> +Ignored Terms: text
> +Ignored Terms: default
> [...]
> +context, specifically: auto behaves as 'text' over text, and 'default' otherwise.

The correct bikeshed markup is ''cursor/text'' and ''cursor/default'' rather than 'text' and
'default', and once you write it that way, you can drop the ignored terms.

 - Florian

Daniel Glazman | 4 Mar 09:05 2015

[csswg] Agenda conf call 04-mar-2015

Time/Phone/SIP details available to WG Members in w3c-css-wg. See

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

0. Digressions

1. Grid Layout

2. CSS Animations editorship

3. Abspos change compat risk
(followup from last week)

4. behavior of MouseEvent.offsetX/Y

5. Reverting vertical % padding/margin to match block

6. unrestricted double in ScrollToOptions

7. behavior of selectors not in the fast profile

8. add property value to allow scrolling without scrollbar


Tantek Çelik | 4 Mar 06:30 2015

[css3-ui] publish WD - all but one outstanding issue resolved / edited.

I have completed pending edits on CSS3-UI on group consensus resolved
issues (including numerous issues resolved during the recent face to
face in Sydney), editorial feedback, and other minor non-substantial
improvements all in what I believe to be according to the technical
consensus of the working group as indicated in f2f, telcons, email,
and IRC.

The one remaining issue, #69, is work in progress that needs further
review, and will take a bit more time to get right, thus I think it is
worth getting an updated working draft out there with the all the
other numerous resolved issues incorporated.


Resolved and other issues that have been incorporated are here:


It would be great to get the TR copy up to date.



Tantek Çelik | 4 Mar 06:16 2015

[CSS3-UI] 'resize' issues 47, 53 - was Re: [CSSWG] Minutes Telecon 2014-12-10

On Fri, Feb 6, 2015 at 8:00 PM, Florian Rivoal <florian <at> rivoal.net> wrote:
>> On 12 Dec 2014, at 04:52, Simon Fraser <smfr <at> me.com> wrote:
>> On Dec 11, 2014, at 11:15 AM, Tab Atkins Jr. <jackalmage <at> gmail.com> wrote:
>>>> - RESOLVED: Implementors may directly manipulate width and height
>>>>     elements on the style attr being changed and change "resize
>>>>     factor" to "resize function" to address fantasai's concern
>>>>     (issues 47 and 53)
>>> I object to keeping the optional hidden resize factor.  Nobody does
>>> it, and to the best of my knowledge nobody plans to; I wouldn't be
>>> surprised if there is code depending on resize causing explicit style
>>> attribute changes.  We should just spec the actual interoperable
>>> behavior and require that, rather than maintaining the polite fiction
>>> of an imagined better world.
>> I agree. This resolution was pushed through at the last minute during the call, and people didn't have
sufficient time to consider the options and voice opinions.
> Just so that we have something concrete written down, resolving in favor of this objection (which I agree
with) would mean changing to text of the spec to something like this (instead of the text that starts with
"When an element is resized by the user", until the example):

<snip> suggested text

I had made simpler edits to address this resolution per what was
recorded during the f2f, however, I took a look at some of the details
in the suggested text.

In particular

> If an element is resized in only one dimension,
> only the corresponding property is set, not both.

This seems like desired behavior and given at least some
implementation we can take it.

> If the 'resize' property is altered after the user has resized an element,
> including if it is changed to ''none'',
> the <a>style attribute</a> is not reset.

This was my expectation as well, but since it was not explicit, I did
add some related text as such.

> ====
> Most of this is what all browsers interoperably do. There are only 2 points where they differ from
eachother, and I'm picking favorites between existing behaviors:
> 1) "If an element is resized in only one dimension,
> only the corresponding property is set, not both."
> webkit and blink always do this. Gecko does it when resize is ''horizontal'' or ''vertical'', but not when
it is ''both'' and the user resizes in along one axis only.

Again I think this is reasonable and if we run into interop issues on
this point we can address during CR.

> 2) "The User Agent must allow the user to resize the element
> within the limits set by [...]"
> Gecko does this, but Webkit/Blink don't, as they block resizing down from the initial size, which is kind
of bad, especially if the page's layout changes after a window resize, screen rotation, etc...

The existing text said "should" per the last time we as a group
discussed the limits (I believe it was on a telcon) and I think that
does a good job of indicating both what we think is better (and is
implemented) behavior, while not having to make it at-risk due to
there being only one implementation.

If we get multiple implementations during CR, I think it is reasonable
to change that to a must.



Tantek Çelik | 4 Mar 06:04 2015

Re: [css3-ui] Issues 40, 72, 75, 80 ime-mode section shouldn't say "Implementations should drop support for it as soon as possible."

On Fri, Feb 27, 2015 at 4:41 AM, Florian Rivoal <florian <at> rivoal.net> wrote:
>> On 27 Feb 2015, at 15:11, Masayuki Nakano <masayuki <at> d-toybox.com> wrote:
>> Hello,
>> First, I don't disagree with dropping ime-mode from CSS3-UI. As I said in 2012, I still believe that
ime-mode shouldn't be standardized due to serious UX problems and bad dependence with platforms and IMEs)
>> http://lists.w3.org/Archives/Public/www-style/2012Feb/0959.html

Thanks Masayuki.

>> However, CSS3-UI spec shouldn't say, "Implementations should drop support for it as soon as possible".

Yes the working group agrees with this request per consensus
resolution to Issue 72.

>> Most ime-mode users, especially enterprise system developers, must be afraid browsers to drop
ime-mode by this. Because if ime-mode were dropped from browsers actually, their system would become
inconvenience than today.
>> I believe that ime-mode is still useful for internet applications in Japan. Therefore, browsers
shouldn't drop such users without providing alternative API or CSS propery. If browsers would drop
ime-mode under current situation, somebody couldn't believe web browsers as stable platform.
>> So, I think that the spec should say "Implementation may keep supporting it *only* for backward
compatibility until alternative feature is standardized".

After the changes that went into the latest public working draft of
CSS3-UI, there was additional discussion in the group, and a
resolution to use "should not" rather than "drop" which was captured
as Issue 72.

Thus the issue you raise about browsers shouldn't drop such users I
believe has already been addressed compatible with your request in the
resolution of issue 72.


<snip> re: lang, inputmode, pattern, type HTML features

> There is a standing issue against css3-ui (https://wiki.csswg.org/spec/css3-ui#issue-75) to refer
to these in the section about ime-mode.

I have also added added an informative note referencing these HTML features.

> I do agree though that some more work in this area is needed before we can consider that a fully functional
replacement to ime-mode is available, but I think it is important to point people to these approaches,
especially since they need more attention.

To put it another way, we know ime-mode is a bad feature, but we have
too little information to suggest a complete replacement for it.

If you have suggestions for a better replacement, please bring them to
the group.

> To keep the essence of your message, while at the same time avoiding suggesting that there is nothing in the
web platform to address this need, I would suggest the following phrasing:
> "Implementation may keep supporting it *only* for backward compatibility until alternative features
are sufficiently developed and supported"

I'm not sure we can make such demands on the future of hopeful
alternative features.

I believe the previously group resolved (per Issue 72) language that
says "User Agents should not support the ime-mode property" provides
sufficient leeway (per should not) for implementations that feel they
must continue supporting it (e.g. for intranet web compat) to do so,
while indicating the working group's technical consensus.



Richard Ishida | 3 Mar 11:02 2015

RTL characters in Ahem

would it be possible to update the Ahem font to include a RTL character 
(such as א)?  (and if we're feeling ambitious, perhaps some arabic 
digits, but a standard RTL character is most needed.)

it would make bidi testing easier.


Daniel Holbert | 3 Mar 01:00 2015

Re: [css-flexbox] Behaviour of percentage heights in column direction

On 03/02/2015 12:39 PM, Daniel Holbert wrote:
> On 02/24/2015 04:51 PM, Daniel Holbert wrote:
>>  (1) This thread here: "should we make 'min-height:auto' taint the resulting flexed height on a vertical
flex item & make it indefinite?" (I slightly lean towards 'yes' for perf reasons; Greg disagrees; I'm OK
either way.)
>> Link to thread (hey, you're already here!):
>>   https://lists.w3.org/Archives/Public/www-style/2015Feb/0205.html
> Answer: no, min-height:auto doesn't make something indefinite.
> * Spec change needed: clarify section 9.8 (1st sentence at least) to mention that "definite sizes" *can*
in fact depend (in part) on content measurements.

Er, actually, Tab's email from later on today[1] seems to contradict this.  (IIUC he's saying there that
min-height:auto *should* make things indefinite.)

So, this issue may still be a bit up in the air.


[1] https://lists.w3.org/Archives/Public/www-style/2015Mar/0025.html

Daniel Holbert | 2 Mar 21:39 2015

Re: [css-flexbox] Behaviour of percentage heights in column direction

Just discussed these 3 issues with Rossen/fantasai/Tab/Greg. Since I've listed all 3 issues all here,
I'll post the results for all 3 here, too.

(For (2) and (3), I'll also post on their own threads as well.)

On 02/24/2015 04:51 PM, Daniel Holbert wrote:
>  (1) This thread here: "should we make 'min-height:auto' taint the resulting flexed height on a vertical
flex item & make it indefinite?" (I slightly lean towards 'yes' for perf reasons; Greg disagrees; I'm OK
either way.)
> Link to thread (hey, you're already here!):
>   https://lists.w3.org/Archives/Public/www-style/2015Feb/0205.html

Answer: no, min-height:auto doesn't make something indefinite.
* Spec change needed: clarify section 9.8 (1st sentence at least) to mention that "definite sizes" *can* in
fact depend (in part) on content measurements.

>  (2) "Should min/max size properties be *actively suppressed* when you have to do layout to resolve the
flex base size?" (Firefox & IE say "yes, suppress them". The spec used to be explicit about this, but became
more vague probably-accidentally, as I noted in the thread.  Chrome disagrees with Firefox/IE & does not
suppress the effects of the min/max sizing properties.)
> Link to thread:
>  https://lists.w3.org/Archives/Public/www-style/2015Feb/0377.html

Answer: yes. This is already implied, but not quite clear enough (particularly given that Chrome/Blink
didn't implement it this way).
* Spec change needed: clarify 9.3.3 D & E to indicate that anything inside of "lay out the item" there
*excludes* min/max clamping.

>  (3) "Should min-content size be considered at all, when resolving min-width:auto on an element with an
intrinsic aspect ratio?" (Firefox says no; it sounds like IE says yes. The spec used to agree with Firefox,
and was then changed -- though it sounded like the rewrite that changed it was just intended to cover more
edge cases, not to change behavior like this.)
> Link to thread:
>  https://lists.w3.org/Archives/Public/www-style/2015Feb/0485.html

Answer: Yes. The current spec text on this (depending on image's min-content size) is intentional & is
needed to prevent images from mysteriously shrinking (by default) in a flex container with e.g. 2 flex
items -- an image and a paragraph of text.

fantasai | 2 Mar 21:20 2015

[css-flexbox] definite flexed size

Tab and I just noticed an error in the definition of "definite"ness
for flex items: the flexed size of an item with a definite flex basis
can only be definite if the flex container's main size is also definite.

We're going to fix this now.


Tab Atkins Jr. | 2 Mar 18:54 2015

Re: [css3-calc()] variable name for static value

On Mon, Mar 2, 2015 at 1:32 AM, Vikas Yadav <vayrsr <at> gmail.com> wrote:
> Css style:
> Div{width:calc(100%-20px);}
> But problem arise here when we use number of tag with calc(). I will change the parent width it
automatically adjust but when use a static value in place of percentage. Change every where. Where use
calc() method but you forget in one place that will be no affect here but layout will be affected so much. You
find the problem and correct it but another alter native solution to defined variable with value. Use
variable name to place value so change in one place and affect in all place.I will recommend of that because
website layout is relative and no need to defined static height and width

Already addressed by <http://dev.w3.org/csswg/css-variables/>; Firefox
and WebKit have implemented it, Chrome intends to soon.