http://blog.gmane.org/gmane.comp.web.css.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.css.general/45105 <pre> Also in this section, # parameter settings which are used s/ which/, which/ ~fantasai </pre> fantasai 2013-05-21T06:59:16 http://permalink.gmane.org/gmane.comp.web.css.general/45104 <pre> Ah, missed an important suggested edit here: s/render/temporarily render/ I think that should help make it clear that you can't keep it that way. :) ~fantasai </pre> fantasai 2013-05-21T06:56:59 http://permalink.gmane.org/gmane.comp.web.css.general/45103 <pre>http://dev.w3.org/csswg/css-fonts/#font-face-loading # The &lt; at &gt;font-face rule is designed to allow lazy loading of # fonts, fonts are only downloaded when needed for use within # a document. Run-on sentence. Suggestion s/fonts, fonts/fonts; that is, fonts/ # user agents may download a font if it's listed in a font # list but is not actually used for a given text run. I would like some clarification: does "listed in a font list" mean: a) specified in a valid 'font-family' declaration b) specified in a valid 'font-family' declaration that matches an actual element in the page c) something else? Also, s/listed in a font list/specified in a 'font-family' list/. # user agents may render text as it would be rendered if # downloadable font resources are not available or they # may render text transparently with fallback fonts to # avoid a flash of text using a fallback font. In cases This is a pretty long sentence already, and the or isn't really exclusive: you have to do the first in order to do the second. So I suggest (changes marked with ^^^) | downloadable font resources are not available. They | ^^^ | may also render such text transparently to avoid a | ^^^^ ^^^^ | flash of text in the fallback font. However, in cases ^^^^^^^^^^ # display text, simply leaving Run on. s/, s/: s/ should work to fix it. # Authors are advised to use fallback fonts in their # font lists that closely match the vertical metrics # of the downloadable s/use/specify/ Question: why are vertical metrics more special than horizontal ones here? http://dev.w3.org/csswg/css-fonts/#same-origin-restriction # Fonts can only be loaded Unless cross-origin loading is enabled? Statement seems overly-generic. # Given a document located at http://example.com/page.html This paragraph and the code block after is should be wrapped in &lt;div class="example"&gt;, since it's an example. # User agents must also implement the ability to relax # this restriction using cross-site origin controls [CORS] # for fonts loaded via HTTP. Suggest moving "for fonts loaded via HTTP" to the front of this sentence, since it scopes the whole paragraph. ~fantasai </pre> fantasai 2013-05-21T06:44:24 http://permalink.gmane.org/gmane.comp.web.css.general/45102 <pre> This totally makes sense to me for the invalid ranges that we're considering parse errors. But there's a bunch of cases that are parsed, kept, but result in no valid range. Specifically, these cases: - "ranges that descend (e.g. U+400-32f) are invalid and omitted rather than treated as parse errors" - "Ranges are clipped to the domain of Unicode code points (currently 0 – 10FFFF inclusive); a range entirely outside the domain is omitted" If it's a parse error, sure, throw the entire declaration out. But I find it a problem to have unicode-range: U+0065, U+400-32f; /* results in range U+0065 */ unicode-range: U+400-32f; /* results in all of Unicode */ Removing a valid &lt;urange&gt; expands the range! I hope you understand why I think this makes no sense. :) ~fantasai </pre> fantasai 2013-05-21T06:06:49 http://permalink.gmane.org/gmane.comp.web.css.general/45101 <pre> Appendix G defines that; there's no such restriction in the Core Grammar. Treating it as Syntax does is perfectly compatible with legacy, because "!important" is not valid for any property. Whether this is the best way to handle it, I'm not sure of, which I explicitly said in my last message. ^_^ ~TJ </pre> Tab Atkins Jr. 2013-05-21T05:48:15 http://permalink.gmane.org/gmane.comp.web.css.general/45100 <pre> Agreed. The entire concept of invalid unicode-range tokens exists only because someone was lazy with the regex defining their syntax; they should always be parse errors when used. The Syntax spec gets rid of this and only recognizes valid ranges. (You can define an empty range if the start is greater than the end, but that's fine. John currently marks those as invalid but only drops them from the list rather than dropping the whole declaration, which is roughly identical to just leaving them be and giving them an empty range.) ~TJ </pre> Tab Atkins Jr. 2013-05-21T05:45:18 http://permalink.gmane.org/gmane.comp.web.css.general/45099 <pre> I think that's both wrong-in-principle and a surprising change from 2.1. Specifically, the 2.1 syntax allows there to be at most one ! in between the : and the ; for a property value and I think we ought to keep it that way. zw </pre> Zack Weinberg 2013-05-21T04:50:54 http://permalink.gmane.org/gmane.comp.web.css.general/45098 <pre> fantasai wrote (regarding the &lt; at &gt;font-face rule unicode-range descriptor): I think there are a couple reasons why this isn't a good idea. I spec'ed the behavior above because it's roughly equivalent to the handling of properties with invalid values: font-style: italic; font-style: whizzy; /* invalid value, font-style: italic used */ Ignoring a descriptor when the ranges aren't valid allows future syntax to be added in a way that an author can also include descriptor declarations for older user agents. For example, if we decide to add a way to specify named ranges to unicode-range: unicode-range: u+3000:ffff; /* all kana/kanji */ unicode-range: range(jis1); /* using new syntax, just the JIS1 subset */ User agents that understood the 'range()' function would use that definition while older user agents would use the first one. I think the existing definition is in better keeping with CSS traditions and the expectations of authors. Cheers, John Daggett </pre> John Daggett 2013-05-21T04:48:25 http://permalink.gmane.org/gmane.comp.web.css.general/45097 <pre>In preparation of the Tokyo face-to-face, I made the compositing spec [1] ready for the next working draft. I added several examples and did general cleanup. During the joint FX day, I would like to discuss the issue of how we can determine what the backdrop of an element with blending is. Specifically: - what CSS constructs create groups that limit the backdrop - how can we specify this and in what spec should we do this - how can we ensure that this can be implement in a interoperable way. 1: https://dvcs.w3.org/hg/FXTF/rawfile/default/compositing/index.html On Fri, Apr 19, 2013 at 1:07 PM, Rik Cabanier &lt;cabanier&lt; at &gt;gmail.com&gt; wrote: </pre> Rik Cabanier 2013-05-21T03:42:02 http://permalink.gmane.org/gmane.comp.web.css.general/45096 <pre> fantasai wrote: In that context what you're describing is "defined within" not "applies to". Conflating descriptors with properties in any way is a bad idea, so we shouldn't be "reusing" fields in the way proposed. Cheers, John Daggett </pre> John Daggett 2013-05-21T03:36:26 http://permalink.gmane.org/gmane.comp.web.css.general/45095 <pre> Well, we have similar things in, for example, &lt; at &gt;counter-style. And probably will have similar things in other at-rules. So I think it does make sense to, in the descdef table, write down the at-rule to which the descriptor belongs. ~fantasai </pre> fantasai 2013-05-21T03:22:34 http://permalink.gmane.org/gmane.comp.web.css.general/45094 <pre> One general comment, since you're going through the spec section by section, could you post your comments with better subject descriptions rather than "Minor comments xxx"? fantasai wrote: For font families defined via &lt; at &gt;font-face rules, font matching occurs via the style descriptors defined in the &lt; at &gt;font-face rules. So the style characteristics defined within font data (e.g. the weight/width values in the OS/2 table) have no effect on the font weight assigned to a particular face. So synthetic faces are created based on whether the set of faces lack italic/bold faces as defined via these descriptor values and *not* what's in the font data for a particular face. For &lt;em&gt; elements in these examples, you'll get synthetic bold in the first one, not in the second one. You'll get synthetic italics in both cases. Yes. A single &lt; at &gt;font-face rule defines a single face and local() refers to a single face, not a family. Cheers, John Daggett </pre> John Daggett 2013-05-21T03:15:56 http://permalink.gmane.org/gmane.comp.web.css.general/45093 <pre> Nope. Descriptors are not properties, there's a whole set stuff in propdefs that don't make sense for descriptors. Here's the 'font-style' descriptor definition in CSS3 Fonts: Name: font-style Value: normal | italic | oblique Initial: normal Why would the definition of a *descriptor* need an "Applies to" line when it's defined as part of the definition of the &lt; at &gt;font-face rule? Cheers, John Daggett </pre> John Daggett 2013-05-21T02:51:03 http://permalink.gmane.org/gmane.comp.web.css.general/45092 <pre>Just a thought - since the "Applies to" line that we use in propdefs (to define what kind of elements the property has an effect on) is meaningless for descriptors, perhaps we can re-use it as a field to define the at-rules that the descriptor applies to. For example, the 'font-style' descriptor in &lt; at &gt;font-face would look like: Name: font-style Value: normal | italic | oblique Initial: normal Applies to: &lt; at &gt;font-face Inherited: N/A Percentages:N/A Media: visual Computed value: as specified Animatable: no Make sense to anyone else? ~TJ </pre> Tab Atkins Jr. 2013-05-21T02:31:09 http://permalink.gmane.org/gmane.comp.web.css.general/45091 <pre> I'm not sure of that, and I don't want to rule out possibilities unnecessarily. According to the current Syntax spec, yes. "Consume a declaration" will strip the last !important off and make the custom property important, with the value "16px !important". I'm not certain this will stay, however; the extensibility aspect of ! things hasn't been explored yet. ~TJ </pre> Tab Atkins Jr. 2013-05-21T02:11:53 http://permalink.gmane.org/gmane.comp.web.css.general/45090 <pre> I meant to say 'it would be "inherit"'. :) var-foo: var(foo) is pretty obscure. I think it probably makes more sense to treat the global keywords as being interpreted here. That seems to be more useful than being able to substitute "inherit" into another property's value. If you do: var-foo: 16px !important !important; font-size: var(foo) is this equivalent to: font-size: 16px !important; ? </pre> Cameron McCormack 2013-05-21T02:00:22 http://permalink.gmane.org/gmane.comp.web.css.general/45089 <pre> Sylvain Galineau wrote: I've trimmed out the term "aliasing" in this context in favor of "substitution", since that refers more specifically to what the spec is trying to describe. The font substitution rules on Windows (via registry settings) or under Linux (via fontconfig) must *not* apply to author-created font family names. Cheers, John Daggett </pre> John Daggett 2013-05-21T01:30:20 http://permalink.gmane.org/gmane.comp.web.css.general/45088 <pre> Tab Atkins wrote: No, I've removed commonly understood information that can be inferred anyways rather than quibble about the semantics of "relative". :P John </pre> John Daggett 2013-05-21T01:20:35 http://permalink.gmane.org/gmane.comp.web.css.general/45087 <pre>I am experimenting with the following: -webkit-transition-timing-function: perfect; -webkit-transition-additive: additive; -webkit-transition-compositing: delta; Eventually I might be experimenting with: -webkit-transition-blend:seamless; and: -webkit-animation-timing-function: perfect; -webkit-animation-additive: additive; -webkit-animation-compositing: delta; I have a working demo that will be pushed to my Github account soon. It is only proof of concept. Eventually I would like there to be additive animations as well. Perhaps transitions would only have a single one-key-enables-all property called "blend" or "seamless" that would produce this shorthand: "both cubic-bezier(.5,0,.5,1) additive delta". This is the first demo page: http://jsfiddle.net/65aEJ/ The "compositing" mode means that the fromValue is the old underlying model value minus the new underlying model value, and the toValue is zero. I think it might also be nice to be able to replicate transition behavior using CSS animations and javascript with an additional compositing property. Perhaps it could determine what values are used when keyframes are left unspecified. It could be used to select whether or not animations use, in Core Animation terms, values from the model layer tree or the presentation layer tree, or this third "delta" mode. It is meant to be conceptually similar to image compositing and blending modes. On Apr 26, 2013, at 6:01 PM, Sylvain Galineau &lt;galineau&lt; at &gt;adobe.com&gt; wrote: </pre> Kevin Doughty 2013-05-20T22:58:19 http://permalink.gmane.org/gmane.comp.web.css.general/45086 <pre>There's no such thing as "implied tokens", though it may make it easier for you to think about it as if there are. Some constructs can simply be closed either by an ending token or by an EOF (or newline, in some circumstances). On Mon, May 20, 2013 at 1:36 AM, Cameron McCormack &lt;cam&lt; at &gt;mcc.id.au&gt; wrote: Valid. The produces the following token stream: HASH(a) WS { WS IDENT(var-x) COLON WS ( WS URL(http://example.org/) In particular, note the url-unquoted state in Syntax, where an EOF is listed alongside ) as a character that just closes the url token validly. Ooh, good question. I think Syntax mandates #1, because parsing will produce a ()-block containing whitespace and a url token. The fact that the () block was closed by an EOF rather than a ) token is lost. I probably do need to define in Syntax how to serialize component values. #3 is right out. ~TJ </pre> Tab Atkins Jr. 2013-05-20T22:40:39 http://permalink.gmane.org/gmane.comp.web.css.general/45085 <pre> Heh, you didn't finish your sentence saying what you thought it would be. ^_^ I'm not sure what the behavior should be, actually. I've logged an issue to track this, and should hopefully fix this by/at the f2f. I'm leaning toward them not being interpreted, in line with values in general. You can already create an invalid value on demand to get the 'inherit' behavior, with something like "var-foo: var(foo);". However, you can't duplicate the "default" keyword's behavior. On the other hand, the global keywords are almost a language-level construct, which just happens to be implemented in the syntax-space of property values. !important is similar, but is handled at the Syntax level, so you can't use top-level ! in a custom property value. (I think in level 2 I'll want some way to type a variable, so you can hook into more CSS functionality, especially the CSSOM Values API, rather than it just always being a bare string.) Excellent question! Logged an issue. ~TJ </pre> Tab Atkins Jr. 2013-05-20T22:35:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.css.general