Kip Gilbert | 1 Oct 20:34 2014

[cssom-view] scroll-behavior CSS property 'auto' value

The CSSOM-View specification, section 14.1 (14.1 Smooth Scrolling: The
'scroll-behavior' Property), describes the 'scroll-behavior' CSS
property as allowing two values, 'instant' and 'smooth':

http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property

The default value, 'instant', may be misleading as many scrolling
actions are animated smoothly by default in our implementation (and
others).  I propose that 'auto' be an allowed value, and be the default.

The value of 'smooth' would remain as defined in the CSSOM-View
specification; however, there would be some distinction between 'auto'
and 'instant'.  'auto' may result in a mixture of smooth and instant
scrolling animations, defined by existing UA behavior.  'instant' will
result in instant scrolling for all events.  If a UA does not scroll
smoothly by default for any events, 'auto' and 'instant' can be
synonymous in their implementation.

In our implementation, smooth scrolling occurs by default with
keyboard scrolling, with scroll-bar interaction, and to align the
scroll offset to snap points for CSS scroll snapping.
(http://dev.w3.org/csswg/css-snappoints/)

Section 14.1 (Smooth Scrolling: The 'scroll-behavior' Property) states:

"The 'scroll-behavior' property specifies the scrolling behavior for a
scrolling box, when scrolling happens due to navigation or CSSOM
scrolling APIs. Scrolls that are performed by the user are not
affected by this property."

(Continue reading)

Tab Atkins Jr. | 1 Oct 18:12 2014
Picon

Re: [css-namespaces] feedback

On Wed, Oct 1, 2014 at 12:10 PM, Joris Lambrecht <oxitech <at> telenet.be> wrote:
> Ehr, yes, possibly.
>
> I assumed i was shooting at the right address.

You've got the right email address, you just put "[css-namespaces]" in
the title, which usually indicates that the email is about the CSS
Namespaces spec.

~TJ

Tab Atkins Jr. | 1 Oct 18:02 2014
Picon

Re: [css-namespaces] feedback

Just to make sure, it looks like this email has nothing to do with the
CSS Namespaces spec, right?

On Tue, Sep 30, 2014 at 8:17 AM,  <commandline <at> telenet.be> wrote:
> Dear,
>
> Thank's for an upgrade to css which we welcome. However, there's something
> which keeps on attracting my attention. Namely the lack of
> modularity-of-designs.
>
> I hope this comment can be seen as a contribution and just maybe as a start
> of a possibly interesting phase in the development of css.
>
> For example, why does the inherit property not enable to extend it with {
> font-size: inherit+1em; } for example ?

When used in font-size, "1em" *is* the inherited value; the "em" unit
corresponds to the value of 'font-size' on the parent.

This doesn't work for every property, of course, but this might get
addressed in the future, when CSS Custom Properties adds a
parent-var() function - I'm pretty sure it's fine to look up the value
of any property on your parent, without circularity issues.

> Or  like {  font-all : inherit;
> font-variant : small-caps; }

The 'font-all' property already exists - it's the 'font' shorthand.

~TJ
(Continue reading)

commandline | 30 Sep 14:17 2014
Picon

[css-namespaces] feedback

Dear,

Thank's for an upgrade to css which we welcome. However, there's something which keeps on attracting my attention. Namely the lack of modularity-of-designs.

I hope this comment can be seen as a contribution and just maybe as a start of a possibly interesting phase in the development of css.


For example, why does the inherit property not enable to extend it with { font-size: inherit+1em; } for example ? Or  like {  font-all : inherit;  font-variant : small-caps; }

To me it seems this would honour inheritance and object oriented design. It would make writing style sheets way more modular and offer natural iheritance inside a design.



Thank you for your consideration,

Joris


Cameron McCormack | 1 Oct 10:52 2014
Picon

[css-font-loading] what happens when you modify a CSS-connected FontFace?

Say I do this:

   <style>
      <at> font-face { font-family: test; src: url(x); }
   </style>
   <script>
     var face = [...document.fonts][0];
     face.load().then(function() {
       face.style = "italic";
     });
   </script>

What happens to face's [[FontStatusPromise]] and its status after 
setting the style descriptor?  The spec doesn't allow for a FontFace to 
go back to loading after it is loaded.

Daniel Glazman | 1 Oct 09:21 2014

[csswg] Agenda conf call 01-oct-2014


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.

Potential regrets: Peter (TAG ftf)

0. Extra agenda items and other digressions
-------------------------------------------

1. TPAC
-------

2. overwriting of an important style
------------------------------------
https://www.w3.org/Style/CSS/Tracker/actions/653

3. Empty string value <media-query> or not
------------------------------------------
http://lists.w3.org/Archives/Public/www-style/2014Sep/0427.html

4. animation-fill-mode and running/completed animations
-------------------------------------------------------
http://lists.w3.org/Archives/Public/www-style/2012Mar/0445.html

5. cssom-view behavior of matchMedia
------------------------------------
http://lists.w3.org/Archives/Public/www-style/2014Sep/0354.html

6. Documents moved to Note or gutted Note
-----------------------------------------
http://www.w3.org/mid/201409301702.45286.bert <at> w3.org

</Daniel>
Greg Whitworth | 30 Sep 23:10 2014
Picon

[css-flexbox] Small editing fix for stretch under align-items

Hello, we found a small edit for 8.3 align-items, it currently reads:

     # Stretch: If the cross size property of the flex item computes to auto, and _either_ of the cross-axis
margins are auto, the flex item is stretched

This should read:

    # Stretch: If the cross size property of the flex item computes to auto, and _neither_ of the cross-axis
margins are auto, the flex item is stretched

Firefox and Chrome currently implement it this way and we are fixing a bug where we stretch all the time even
with auto set and found this. 

Here is an example with the cross margin-top set to auto on one of the flex items but it doesn't stretch like
that of the one without auto margins: http://jsfiddle.net/0dfdqL09/6/

Thanks,
Greg

Nigel Megitt | 30 Sep 18:35 2014
Picon
Picon

Call for Review: TTML Text and Image Profiles for Internet Media Subtitles and Captions 1.0

Dear CSS Working Group,

(1) This is a Call for Review for a Working Draft
Transition for the following Recommendation Track specification:


(2) Document Title and URI:

* TTML Text and Image Profiles for Internet Media Subtitles and Captions
1.0
http://www.w3.org/TR/2014/WD-ttml-imsc1-20140930/



(3) Instructions for providing feedback

If you wish to make comments regarding this document, please send them
to public-tt <at> w3.org  with [imsc] at the start of your email's subject.
All comments are welcome.


(4) Review end date

The review period ends on 27 October 2014.


(5) Reference to the group's decision to make this Transition

Timed Text Working Group made the decision to
publish this Working Draft for wide review
http://lists.w3.org/Archives/Public/public-tt/2014Sep/0136.html



(6) Evidence that the document satisfies group's requirements. Include a
link to requirements

No requirements were defined for this specification in the Timed Text
Working Group's charter at
http://www.w3.org/2014/03/timed-text-charter.html



(7) The names of groups with dependencies, explicitly inviting review
from them.

The following groups are known or suspected to have dependencies on this
specification:

- HTML Working Group
- Protocols and Formats Working Group
- HTML Accessibility Task Force
- CSS Working Group
- Web Content Accessibility Guidelines Working Group


also the following groups have liaisons on one or more of these
specifications:
- Scalable Vector Graphics (SVG) Working Group
- Web and TV Interest Group
- Web Media Text Tracks Community Group
- Internationalization (i18n) Working Group

The Timed Text Working Group requests review from each of these
working groups. The chairs of the working group listed have been copied
on the distribution list of this transition announcement as well as
other individuals known to have expressed prior interest.


(8) Report of any Formal Objections

The Working Group received no Formal Objection during the preparation of
this specification.


(9) Patent Disclosure Page Link can be found at
http://www.w3.org/2004/01/pp-impl/34314/status


This document is governed by the 1 August 2014 W3C Process Document.


(10) Abstract

This document specifies two profiles of [TTML1]: a text-only profile and
an image-only profile. These profiles are intended to be used across
subtitle and caption delivery applications worldwide, thereby simplifying
interoperability, consistent rendering and conversion to other subtitling
and captioning formats. The text profile is a superset of [SDPUS].

The document defines extensions to [TTML1], as well as incorporates
extensions specified in [ST2052-1] and [EBU-TT-D].

Both profiles are based on [SUBM].


(11) Status of this document

This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports index at http://www.w3.org/TR/.


The Timed Text Working Group plans to recommend transition of this
document to Candidate Recommendation and is offering this Working Draft
for a public review period, which ends on 27 October 2014.
This document was published by the Timed Text Working Group as a Working
Draft. This document is intended to become a W3C Recommendation. If you
wish to make comments regarding this document, please send them to
public-tt <at> w3.org (subscribe, archives) with [imsc] at the start of your
email's subject. All comments are welcome.

Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.

This document was produced by a group operating under the 5 February 2004
W3C Patent Policy. W3C maintains a public list of any patent disclosures
made in connection with the deliverables of the group; that page also
includes instructions for disclosing a patent. An individual who has
actual knowledge of a patent which the individual believes contains
Essential Claim(s) must disclose the information in accordance with
section 6 of the W3C Patent Policy.

This document is governed by the 1 August 2014 W3C Process Document.



(12) Dependencies

The specification has the following normative references:
[CLDR]
	Unicode Consortium. The Common Locale Data Repository Project
[EBU-TT-D]
	European Broadcasting Union (EBU). Tech 3380, EBU-TT-D Subtitling
Distribution Format Version 1.0
[MHP]
	ETSI TS 101 812 V1.3.1, Digital Video Broadcasting (DVB); Multimedia Home
[RFC2119]
	S. Bradner. Key words for use in RFCs to Indicate Requirement Levels.
March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt

[ST2052-1]
	SMPTE ST 2052-1, Timed Text Format (SMPTE-TT)
[TTML1]
	Glenn Adams, Ed., Timed Text Markup Language 1 (TTML1) (Second Edition),
W3C Recommendation, 24 September 2013. URL:
http://www.w3.org/TR/2013/REC-ttml1-20130924/

[UNICODE]
	The Unicode Standard. URL: http://www.unicode.org/versions/latest/

[WCAG20]
	Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et
al. Web Content Accessibility Guidelines (WCAG) 2.0. 11 December 2008. W3C
Recommendation. URL: http://www.w3.org/TR/WCAG20/

[xml-names]
	Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et
al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. W3C
Recommendation. URL: http://www.w3.org/TR/xml-names






Regards,

Nigel Megitt, Chair of the Timed Text Working Group.
Thierry Michel, Team Contact for the Timed Text Working Group.


Simon Pieters | 30 Sep 12:05 2014
Picon

[mediaqueries][css-values] Empty string value <media-query> or not

What is the correct interpretation of this grammar:

a? | b

If a is omitted, it does not occur (or occurs zero times), but | requires  
one of them to occur, so my understanding is that the above is equivalent  
to:

a | b

http://dev.w3.org/csswg/css-values/#mult-opt
http://dev.w3.org/csswg/css-values/#comb-one

Either way, it's confusing. Please make it clearer.

This is relevant for  
http://dev.w3.org/csswg/mediaqueries-4/#typedef-media-query

In particular, consider this media query list: ","

If the empty string matches <media-query> production then there are two  
empty <media-query>s (it's not defined if it matches or not AFAICT).

If the empty string does not match <media-query> production then it's  
equivalent to "not all,not all" per the error recovery rules (this matches  
Trident/WebKit/Blink/Gecko/Presto).

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3216

If the interoperable browser behavior is intended, please remove the  
question mark.

--

-- 
Simon Pieters
Opera Software

Jens O. Meiert | 29 Sep 14:40 2014

[css-display] Initial value of display

When I look at all the properties in CSS Display [1], specifically
display, and then the display property’s characteristics in CSS 2.1
[2], I wonder, is the old “inline” initial value indeed mapping 1:1 to
the new display-outside’s “inline-level”?

Just to make sure I don’t miss something, or that we’re running into
an incompatibility here.

[1] http://www.w3.org/TR/css-display-3/#property-index
[2] http://www.w3.org/TR/CSS21/visuren.html#display-prop

--

-- 
Jens O. Meiert
http://meiert.com/en/

Cameron McCormack | 29 Sep 08:31 2014
Picon

[css-font-loading] FontFace objects representing the same set of descriptors

In Gecko, we have a cache of objects that represent loadable font faces. 
  This means that if you use the same  <at> font-face rule on multiple pages 
in the same origin, then we only download the font resource and create 
OS font objects once.  The cache gets exercised frequently, as it's 
common to navigate to pages on the one site that all use the same style 
sheets with the same  <at> font-face rules.

We've discovered that this means in our Font Loading API implementation, 
that if one page starts loading a FontFace, then this will cause the 
FontFace object in another page to have its status set to loading too, 
and eventually have its loaded property resolved.

This isn't so much of a problem with CSS-connected FontFace objects, 
since the implementation can choose to start loading them whenever it 
feels like it, really.  But it does mean that unconnected FontFace 
objects can appear to start loading without the author explicitly 
loading them.

This happens for FontFace objects in the same page, too.  For example:

   var f1 = new FontFace("ABC", "url(x)");
   var f2 = new FontFace("ABC", "url(x)");

   f1.load().then(function() {
     alert(f2.status);
   });

will alert "loaded", even though we didn't touch f2 explicitly.

My question is whether a FontFace object that is not in the FontFaceSet 
to start loading like this.


Gmane