http://permalink.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/45245 <pre> Unfortunately, the SVG spec has a different definition on how the backdrop is calculated, see https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#enable-background As I previously mentioned, that definition is incorrect so I believe we should 'enable-background' and harmonize SVG with CSS. At a later point in time, we can add support for non-isolated groups which is what the SVG spec attempted to do. IE did implement this though so we need to tell them to update their browser. Hopefully few people used this. If they did, maybe we can define it in a way that is still backward compatible. </pre> Rik Cabanier 2013-05-25T03:56:22 http://permalink.gmane.org/gmane.comp.web.css.general/45243 <pre>Le 25/05/2013 09:30, Tab Atkins Jr. a écrit : In addition to being weird, we’d have to find some way to break the definition cycle that usually prevented by this part of css3-mediaqueries: For example, how would this work? :root { var-my-query: (min-width: 600px) } &lt; at &gt;media var(my-query) { :root { var-my-query: (max-width: 600px) } } </pre> Simon Sapin 2013-05-25T02:31:23 http://permalink.gmane.org/gmane.comp.web.css.general/45242 <pre> It does make more sense when you say it like that. (Not that I favor it over &lt; at &gt;region, mind you.) I guess I would too. It's too long to type, but its what the fragmentation spec call those things that contain the fragments. </pre> Brad Kemper 2013-05-25T01:43:40 http://permalink.gmane.org/gmane.comp.web.css.general/45241 <pre> Variables are defined by custom properties, which are nothing more than ordinary CSS properties. Media Queries don't exist in a context where they can access properties from some object, so CSS Variables aren't useful for them. We could possibly say that properties defined on the root element are accessible across the stylesheet, but that might be weird. ~TJ </pre> Tab Atkins Jr. 2013-05-25T01:30:38 http://permalink.gmane.org/gmane.comp.web.css.general/45240 <pre>Media queries are very common, both in their CSS form and as a `media` attribute. RWD often results in media query break points repeated in various places in the code. In CSS, authors have been using preprocessors to DRY up media queries from the code, place them in a single location and give them meaninful names [3] [4] In HTML, the media attribute can be used with &lt;link rel=stylesheet&gt; and with &lt;source&gt; tags. There are a few new proposals that rely on the media attribute [1][2] (I'm involved with both). Considering RWD's reliance on media queries, there may be more to come. Therefore, authors need to DRY up the actual media queries from markup and CSS, and give them short and meaningful names. That need is likely to increase over time, with RWD becoming more and more popular and with an ever-increasing device variance. Having a standard way to do that will ease code readability and authoring, and will result in slightly smaller files. At least one proposal have been made to address this issue [5], but </pre> Yoav Weiss 2013-05-24T22:29:25 http://permalink.gmane.org/gmane.comp.web.css.general/45239 <pre> I know Blink/WebKit hasn't started working on it yet. I'm not opposed to punting if no one's going to implement it soon. ~TJ </pre> Tab Atkins Jr. 2013-05-24T17:48:05 http://permalink.gmane.org/gmane.comp.web.css.general/45238 <pre>On Fri, May 24, 2013 at 9:03 AM, Christopher Palmer (BLOOMBERG/ 731 LEXIN) &lt;cpalmer18&lt; at &gt;bloomberg.net&gt; wrote: It's not quite a standard transition. For example, a simple notion of 'duration' isn't really useful - you want the duration to somewhat reflect the distance being travelled (not in a linear fashion, probably more like logarithmic). I think the browser is in a good position to figure out a "good" transition for this. ~TJ </pre> Tab Atkins Jr. 2013-05-24T17:05:10 http://permalink.gmane.org/gmane.comp.web.css.general/45237 <pre> I don't really understand this. The issues in SVG are a strict subset of the issues in HTML. We should make SVG follow HTML and dispense with "enable-background". Filters, blending and opacity should probably cause isolation... The spec says stacking contexts cause isolation, so these already do. Rob </pre> Robert O'Callahan 2013-05-24T16:45:49 http://permalink.gmane.org/gmane.comp.web.css.general/45236 <pre> Well, maybe. Currently the spec says "However certain operations that cause the creation of stacking context (such as 3D transforms or a non-default blend mode) [CSS21] will cause a group to be isolated. This behavior is described in more detail in Isolated Gropus." [sic] However, nothing in the spec describes exactly what induces an "isolated group". Also, I think every isolated group needs to be a stacking context since we can't allow two elements in an isolated group to have other content not in the group inserted between them in z-order. So every element that's an isolated group would have to be a stacking context, and every element that's a stacking context would have to be an isolated group, so they're almost exactly the same thing. Except that SVG images rendered in CSS or via &lt;img&gt; are also isolated groups. If we do that, I think we can probably implement this in our compositor. For every element that requires non-standard blending with the background, we'd find the nearest ancestor stacking con</pre> Robert O'Callahan 2013-05-24T16:43:53 http://permalink.gmane.org/gmane.comp.web.css.general/45235 <pre>Does it make sense to additionally allow the user control on the type of smooth scrolling they want? Something like smooth-linear, smooth-ease-in-out, etc? This seems a lot like a standard transition, and I would assume users would want the same types of controls over it. Specifying duration also comes to mind. </pre> Christopher Palmer (BLOOMBERG/ 731 LEXIN 2013-05-24T16:03:15 http://permalink.gmane.org/gmane.comp.web.css.general/45234 <pre> Just as ::first-line is selecting a portion of the content, ::fragment would select the portion of the content that falls inside the container(s) matched by the &lt;region-selector&gt;. The pseudo-element is modifying the &lt;content-selector&gt;, so I think 'fragment' works. I'm reading this: &lt;content-selector&gt;::fragment(&lt;region-selector&gt;) {} As "the content's fragment that is rendered inside this region" I'd object to adding the term 'fragmentainer' to the syntax. Thanks, Alan </pre> Alan Stearns 2013-05-24T16:09:20 http://permalink.gmane.org/gmane.comp.web.css.general/45233 <pre> On May 23, 2013, at 5:24 PM, Alan Stearns &lt;stearns&lt; at &gt;adobe.com&gt; wrote: Right. Which is one of the things that makes it hard to read as a pseodo-element. Another difference is that with '::first-line', one rule with the pseudo-element tacked to the end is generally enough for setting the font, text, and color properties for the thing you want to style. But for regions and pages, there may be many things you want to select for a variety of style changes for when they appear within that fragmentainer. And these are huge reasons, to my mind, to not try to shoehorn region styling into something like first-line's pseudo-element structure. That would be confusing, since "fragment" describes the thing inside the fragmentainer. Doesn't it? I think it would be less confusing thusly: &lt;content-selector&gt;::fragmentainer(&lt;region-selector&gt;) {} </pre> Brad Kemper 2013-05-24T15:54:20 http://permalink.gmane.org/gmane.comp.web.css.general/45232 <pre>On Wed, 15 May 2013 19:04:40 +0200, Tab Atkins Jr. &lt;jackalmage&lt; at &gt;gmail.com&gt; wrote: Done. https://dvcs.w3.org/hg/csswg/rev/009ff568218a https://dvcs.w3.org/hg/csswg/rev/1fce354eb139 </pre> Simon Pieters 2013-05-24T13:48:29 http://permalink.gmane.org/gmane.comp.web.css.general/45231 <pre>A few copy-editing issues that caught my eye on reading through the Editor's Draft today, plus some issues where I think the text could use clarification. JK - - - - - - - - - - (Status) # This is a public copy of the editors' draft. s/editors'/editor's/ - - - - - - - - - - (3.1) # Font family names must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This seems a little confusing: just above this, you say that &lt;generic-family&gt; names, being keywords, must not be quoted; but then this section says that font family names (of which &lt;generic-family&gt; is one type) can be given "quoted as strings". - - - - - - - - - - (3.1) # monospace # The sole criterion of a monospace font is that all glyphs have the same fixed width. This is often used to render samples of computer code. Is this intended to exclude fonts that support any combining diacritics (having zero width) from being considered "monospace"? - - - - - - - - - - (4.4) # User agents that impleme</pre> Jonathan Kew 2013-05-24T10:32:25 http://permalink.gmane.org/gmane.comp.web.css.general/45230 <pre>Hi fantasai, Welcome to Taipei! I'm Bobby Tung. Now I'm going to write a proposal of Traditional Chinese Layout Requirement. Maybe I can reply your question. About punctuations, Ministry of Education published their rule in 2000. In which didn't strictly forbidden some of them appear on start/end of lines. But publishers have basic rules for that as Japanese typesetting. Unfortunately, they are never written down as a rule book. Newspaper may be an exception, because it's short line hard to avoid line-start/line-end prohibition rule. About emphasis, I cannot figure out what you seen actually. But Ethan had published a sample to make layout better on web. http://ethantw.net/projects/han/ Actually in Traditional Chinese Books, when meets &lt;em&gt;, we never use italic font for that, and seldom use "徬點"(emphasis dots). Usually just bold and in sans-serif font(黑體). And sample you provided: That is not acceptable by publishers definitely. combination of: p{ text-align: justify; text-just</pre> 董福興 Bobby Tung 2013-05-24T07:08:25 http://permalink.gmane.org/gmane.comp.web.css.general/45228 <pre> My point is that nothing in the grammar section depends on Syntax. It's not defining a CSS feature, just a way for us to *describe* CSS features. We could move it to the end-of-spec boilerplate, or the wiki, or literally anywhere else, because it has no relevance for conformance. It's at the same level as the description of the property grammars, or the description of the propdef table structure. Ah, yeah, missed that. ~TJ </pre> Tab Atkins Jr. 2013-05-24T04:48:13 http://permalink.gmane.org/gmane.comp.web.css.general/45227 <pre> I agree with that. :) I do think some reordering of sentences would be in order here. http://lists.w3.org/Archives/Public/www-style/2013May/0576.html ~fantasai </pre> fantasai 2013-05-24T04:37:36 http://permalink.gmane.org/gmane.comp.web.css.general/45226 <pre> Fair enough. In which case, s/9 pixels/9px/ :) ~fantasai </pre> fantasai 2013-05-24T04:26:38 http://permalink.gmane.org/gmane.comp.web.css.general/45225 <pre>I'm in Taipei at the moment, and have seen multiple examples, in newspapers and in signage, of lines beginning with closing quotes, closing parens, periods, and commas; and of lines ending with opening quotes/parens. Things that would never be allowed in Japanese typesetting, and which are forbidden by PRC's 标点符号用法. I am wondering if this difference arises from Taiwanese typography's stronger emphasis on the character grid, and the way they set their punctuation centered within the em-box. I would hope it's not just sloppy typesetting engines! The readers here don't seem to find such line breaks odd in newspapers and magazines, and would write on grid paper this way (as for homework in school). They explain to me that for them, a punctuation character is like a word, too. But on non-gridded paper, they would not write this way. (They're surprised when I point this out, though.) I am wondering if the definition of 'line-break: loose' should be modified so that zh-Hant or zh-TW allows such break</pre> fantasai 2013-05-24T04:18:48 http://permalink.gmane.org/gmane.comp.web.css.general/45224 <pre> Tab Atkins wrote: Um, "a convenient place to put the definitions" and their precise definition is the very essense of "dependence"!! Look more carefully: Only named font families are allowed for &lt;font-family&gt;, rules that include generic or system fonts in the list of font families are considered syntax errors and the contents of the rules are ignored. That said, I should probably move that sentence so that it's closer to the syntax. Yeah. Cheers, John Daggett </pre> John Daggett 2013-05-24T04:14:48 http://permalink.gmane.org/gmane.comp.web.css.general/45222 <pre> It depends on Syntax as much as property grammars depend on Values - not really at all, the given spec is just a convenient place to put the definitions. That said, if you'd like to shelve the suggestion until the F2F, that's fine too. Defined in the description of the grammar in Syntax - !important is never valid in descriptors. (If this ever changes, I can just update the rules to say that !important is invalid in descriptors by default.) I don't see any such restriction in the spec - the token grammar just uses font_family_list, and the paragraph following says it "uses the same syntax as that used for the ‘font-family’ property". In any case, that's a trivial fix (and the reason for the edit that caused the initial screwup) - just use &lt;family-name&gt;# instead of &lt;'font-family'&gt;. ~TJ </pre> Tab Atkins Jr. 2013-05-24T03:40:34 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.css.general