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://comments.gmane.org/gmane.comp.web.css.general/36694 <pre> It's not clear to me with this change (or with the current spec text) what should happen with flex-align/align-items: stretch on absolutely positioned flex items. WebKit's current implementation happens to ignore stretch, but that's not intentional. I can't really think of use-cases for wanting to stretch absolutely positioned items, except if you're trying to overlay one item on top of the other. Ojan </pre> Ojan Vafai 2012-05-26T03:54:57 http://comments.gmane.org/gmane.comp.web.css.general/36684 <pre>This is just a general preference question for implementors. When I pick up Syntax again, would it be better for me to write the parsing section as if it the tokenizing was already completely done, or interleaved with the tokenizing like the HTML parser is? What would be more useful? I can do either, but I'd rather not have to switch partway through, or even after I'm totally done. ~TJ </pre> Tab Atkins Jr. 2012-05-25T22:08:43 http://comments.gmane.org/gmane.comp.web.css.general/36679 <pre>Apologies if this is dense... I'm just wondering if some can explain why having usage and reference match is desirable? Tab has said several times that he wanted it to match and some other at w3c did too... Ok, I can respect that I, but can someone explain why it is desirable? It's non-obvious to me. Several people (myself included) have raised all kinds of contentions, some debated and deemed invalid and some not. I posted some thoughts advocating why not [1] but that thread quickly went downhill as $ on the left making some people assume that either: a) that was a variable reference (it wasn't) or b) not being able to have a variable reference on the left was a bad idea (I think it isn't) and therefore an argument against $ for declaration (I don't think it is, but the confusion that ensued might be). I'm definitely not saying it is _wrong_ or anything, just that I can only reasons that it doesn't seem desirable right now... Can someone share the reasons it is? - Brian [1] - http://lists.w3.org/Ar</pre> Brian Kardell 2012-05-25T21:22:18 http://comments.gmane.org/gmane.comp.web.css.general/36642 <pre>Sorry, but I am totally lost here. Too much signal. Tab, I know it's yet another thing added to your radar but could you please try to gather a summary of the recent discussions on variables? I am totally lost about the $ notation, what changes you accepted or not, which ones you consider or not. BTW, the Editor's draft has no "Changes from last version" section ;-) &lt;/Daniel&gt; </pre> Daniel Glazman 2012-05-25T14:57:06 http://comments.gmane.org/gmane.comp.web.css.general/36639 <pre>so, i'd like to understand (before proposing a change) to why css styling does not follow the order in which classes are added to an element but instead an element gets styled in the order classes are found in the stylesheet. if there's a webpage with an explanation i'd like to read it, so if someone could point me there that would be great. i find it very counter-intuitive, not to apply styles in the order they are added to an element, but i'm sure there's a reason.. </pre> ricmetal 2012-05-24T02:59:02 http://comments.gmane.org/gmane.comp.web.css.general/36632 <pre>Hi, Consider an absolutely positioned, replaced element with: top and margin-top are 'auto' bottom and margin-bottom are not 'auto' If I am reading correctly, this case is not covered by the current wording of 10.6.5. Proposed change: In step 3, replace "If 'bottom' is 'auto'" by "If 'top' or 'bottom' is 'auto'". This matches the corresponding step 3 in 10.3.8. Regards, </pre> Simon Sapin 2012-05-25T12:03:05 http://comments.gmane.org/gmane.comp.web.css.general/36629 <pre>Hello, In Working Draft 7 there was a predefined counter style "hyphen" with the value \2013 (en-dash). In Working Draft 24 it has been replaced with "dash" with the value \2014 (em-dash). Is there a reason why both couldn't be allowed? Best regards, Werner. -- http://www.pincette.biz/ Handling your documents with care, wherever you are. </pre> Werner Donné 2012-05-25T10:00:36 http://comments.gmane.org/gmane.comp.web.css.general/36624 <pre>Hello, The value of the "bookmark-label" property should be a list, reminiscent of the "content" property, because the various content parts could be rearranged. The following example uses some fancy typesetting for titles. The chapter number comes after the title, is much larger and is right-aligned. For the bookmark label it would be normal to expect the number before the title, because no fancy typesetting is desired in that context. h1 { bookmark-label: content-after " " content-element; margin-bottom: 2.4em; text-align-last: justify; } h1:after { content: leader(space) counter(h1); font-family: serif; font-size: 3em; font-style: italic; text-transform: uppercase; } Best regards, Werner. -- http://www.pincette.biz/ Handling your documents with care, wherever you are. </pre> Werner Donné 2012-05-25T08:30:21 http://comments.gmane.org/gmane.comp.web.css.general/36608 <pre>I couldn't find anything about this from a cursory search of the list. Has any thought been given to exposing when fonts in &lt; at &gt;font-face are loaded? (Where "loaded" means "one of the sources is either successfully downloaded and parsed, or is successfully found on the local system, or all the sources fail".) Our Docs team needs to know this information so it can do accurate measurements of things, which are based on the metrics of the font being used. If a fallback font is being used because the main one hasn't loaded yet, we'll do an initial sizing sweep, then watch for the load using silly indirect means so we can redo all the sizing when it loads and we swap out the fonts. Right now, our technique is to render two spans positioned off-screen, one with the fallback font and one with the &lt; at &gt;font-face font, and poll the sizes on a timer until the second is a different size than the first. This is, of course, very silly. It's also not reliable - if the fallback font happens to produce a span the same width</pre> Tab Atkins Jr. 2012-05-25T00:26:45 http://comments.gmane.org/gmane.comp.web.css.general/36600 <pre>There's been a decent bit of feedback recently about the 'dppx' resolution unit, since Responsive Images have become popular over in HTML. The feedback has pretty much all been negative about the name, though. It seems to be generally considered to be a difficult name to read and even write (with a lot of 'ddpx' typos, even from people here in the WG). Apple's image-set() proposal, and HTML's new &lt;img srcset&gt; proposal, both use a simple 'x' unit to denote the same thing. What do we think about doing the same thing? I see two ways this could happen: 1. We modify the Images 3 CR. In the absence of a CR errata mechanism, this means another Last Call, though we could certainly annotate the draft to make it clear that it's not a big deal, or simply keep it low-key like we did with B&amp;B recently. 2. We wait for Images 4 and add it, deprecating dppx along the way. We can either invoke an explicit aliasing mechanism here, or just define it identically and say that authors must not use dppx. Thoughts? ~TJ </pre> Tab Atkins Jr. 2012-05-24T21:41:53 http://comments.gmane.org/gmane.comp.web.css.general/36579 <pre>Hi, The bookmark-label property has 5 possible keywords in its Value line, but does not define them. It should probably reference the string-set property, as the keywords seem to be the same. Example 35 includes "bookmark-label: attr(title, string)", but the attr() syntax is not in the Value line. Lastly, I think that the label strings, at least when taken from the document, should go through the normal whitespace processing. For example: &lt;h1 style="bookmark-label: contents"&gt; This title is a bit long but that should not be a problem. &lt;/h1&gt; Assuming the initial value for the 'white-space' property, the used value for bookmark-label should not include newlines or multiple consecutive spaces. (Maybe this should not apply to &lt;string&gt; values, though.) Regards, </pre> Simon Sapin 2012-05-24T13:30:59 http://comments.gmane.org/gmane.comp.web.css.general/36572 <pre>Summary: - RESOLVED: John's proposal to resolve the issue is accepted, exact wording to be settled on list - RESOLVED: Alignment properties to be named align-self / align-content / align-items justify-self / justify-content / justify-items - RESOLVED: use space-between/space-around instead of justify/distribute - RESOLVED: rename flex-order to order ====== Full minutes below ====== Present: Glenn Adams Rossen Atanassov Tab Atkins Phil Cupp David Baron Ryan Betts Bert Bos John Daggett Elika Etemad Simon Fraser Sylvain Galineau Daniel Glazman John Jansen Brad Kemper Peter Linss Edward O'Connor Anton Prowse Florian Rivoal &lt;RRSAgent&gt; logging to http://www.w3.org/2012/05/23-css-irc Scribe: sylvaing glazou: other agenda items? font-family syntax and reserved keywords ---------------------------------------- &lt;jdaggett&gt; http://lists.w3.org/Archives/Public/www-style/2012May/0630.html &lt;jdagget</pre> fantasai 2012-05-24T04:42:04 http://comments.gmane.org/gmane.comp.web.css.general/36571 <pre>The WG resolved to change 'flex-order' to just 'order', rather than to 'box-order' or 'display-order', which were proposed before the call. This name is *very* generic, and brings up the following questions: 1. Does it affect z-order? 2. Does it affect tab-order? 3. Does it take effect in speech media as well as visual? If the answer to the latter two is "no", then I'd like to reconsider whether 'order' is the right name here. ~fantasai </pre> fantasai 2012-05-24T01:15:05 http://comments.gmane.org/gmane.comp.web.css.general/36546 <pre>Section 3.1.1. of the CSS3 Exclusions spec is currently defining the value 'maximum' for the 'wrap-flow' property but there isn't the symmetrical 'minimum' value. This was partially an overlooked issue and partially because we didn't have a major use case for it. However, having properties that are not symmetrical is pretty weird, thus we are adding the value to the ED unless someone has a strong argument otherwise. Thanks, Rossen </pre> Rossen Atanassov 2012-05-23T18:44:58 http://comments.gmane.org/gmane.comp.web.css.general/36539 <pre>We got through three of the naming issues today on the call, with only one remaining to be discussed on the list. The secret of naming discussions, apparently, is to let everyone brainstorm for a bit, then quickly call for a poll and end the discussion. The three we solved are: 1. http://wiki.csswg.org/topics/alignment-names - resolution is to go with Option 4: justify-self/content/items and align-self/content/items 2. http://wiki.csswg.org/topics/justification-keywords - in a nail-biting 7-6 decision, we went with space-between/around instead of justify/distribute 3. http://wiki.csswg.org/topics/css3-flexbox-rename-flex-order - resolution is option D (not on the wiki) and use plain 'order' as the property name The only remaining naming bikeshed is the start/end keywords in the 'align-*' properties &lt;http://wiki.csswg.org/topics/start-end-before-after-align&gt;. We have two options: 1. The current world, where both justify-* and align-* use "start" and "end". 2. More closely match the logical axises, an</pre> Tab Atkins Jr. 2012-05-23T17:31:15 http://comments.gmane.org/gmane.comp.web.css.general/36532 <pre> I'm trying to understand the inline formatting model's behavior in regards to inline box splitting with padding. Specifically, why is it that when an inline box has right padding that is distributed to the following line, it takes preceding text (words) with it, even though there's still room for those words on the initial line box. Furthermore, the wider the padding, the more text is displaced to the following line box. Here is an example where the right padding (46px wide) ends just at the end of the line box: http://tinkerbin.com/ZmmhofCB Here is the same example where the padding is one pixel wider, causing the browser to displace the padding to the following line box. Why is the word "top" also displaced? http://tinkerbin.com/QI1s35Lq And the wider the padding is made, the more text is displaced to the following line box... 100px displaces the words "at the top": http://tinkerbin.com/67xb2Ef4 200px displaces the words "other, beginning at the top": http://tinkerbin.com/Gr0tVzNd And so on. Per</pre> Roger Baker 2012-05-23T13:09:57 http://comments.gmane.org/gmane.comp.web.css.general/36530 <pre>Time/Phone/SIP details available to WG Members in w3c-css-wg. See https://lists.w3.org/Archives/Member/w3c-css-wg/2012JanMar/0168.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. syntax of font-family and reserved keywords ---------------------------------------------- (10 minutes max ; first item because of jdagget's TZ) http://lists.w3.org/Archives/Public/www-style/2012May/0063.html http://people.mozilla.org/~jdaggett/tests/font-family-parsing.html http://lists.w3.org/Archives/Public/www-style/2012May/0630.html 2. Flexbox --------------------- http://wiki.csswg.org/topics?datasrt=&amp;dataflt[]=spec%3Dcss3-flexbox 3. CSS 2.1 ---------- https://lists.w3.org/Archives/Member/w3c-css-wg/2012AprJun/0223.html 4. Left-overs from Hamburg ftf ------------------------------ - Prefixes - FPWD CSS3 text-size-adjust - Changing the prefix policy? - Device adaptation - M</pre> Daniel Glazman 2012-05-23T12:27:16 http://comments.gmane.org/gmane.comp.web.css.general/36511 <pre>Hello, In the great example 2 in section 5.1, I think there is a small typo: the remaining percentage value in the 3rd bullet should be 58.16% instead of 48.16% I believe (so as to add up to 100% with the previous 41.84%). Cheers, Vincent </pre> Vincent Hardy 2012-05-23T02:09:32 http://comments.gmane.org/gmane.comp.web.css.general/36503 <pre>(I'm just choosing a couple of properties from css3-text as an example.) The "Computed value" line for the tab-size property definition says "specified value". css3-values however says that "Child elements do not inherit the relative values as specified for their parent; they inherit the computed values." Does css3-values override the tab-size definition here? Or does "specified value" mean "the same value that was specified but with all of the computed value changes that are required elsewhere"? This is in contrast to word-spacing, which says "as specified, except with &lt;length&gt; values computed to absolute lengths", so it's explicitly calling out the computation of &lt;length&gt;s. Also, when it is stated that &lt;length&gt;s are converted into absolute lengths, does that mean any of the absolute length units are allowed (like cm)? I ask because I wonder whether property definitions in SVG need to mention &lt;length&gt; computation explicitly in their "Computed value" lines, or whether this will happen auto</pre> Cameron McCormack 2012-05-23T01:13:54 http://comments.gmane.org/gmane.comp.web.css.general/36493 <pre>A common pattern in the web is to use `element.scrollIntoView()` to show that element in the context of the web page. However, the design of scrollIntoView puts that element either at the very top or at the very bottom of the viewport. In most cases, web authors want to center that element. As a result, there is great duplication of code to make that work, and scrollIntoView gets rarely used, except for quick and dirty implementation of a search functionality. I suggest a solution to that in the following bug, copy and pasted below. All feedback is warmly welcome! https://www.w3.org/Bugs/Public/show_bug.cgi?id=17152 --- The main reason why we might use `scrollIntoView()` is to bring an element into the viewport. However, showing that element at the top or at the bottom of the viewport is detrimental to understanding the context in which this element is. As a result, what authors really want is to center the element. I know we are implementing that in JS again and again throughout Firefox, and web de</pre> Thaddee Tyl 2012-05-22T22:17:13 http://comments.gmane.org/gmane.comp.web.css.general/36488 <pre>I noticed that IE9 is a bit different from other browsers in that it serializes an arbitrary media type as "unknown" instead of the original input. This turns out, as far as I can tell, not to create a non-conforming case as css3-mediaqueries doesn't say very clearly that a UA has to store the unknown media types. Some options: A. Don't change the spec and keep it as it is. B. Explicitly ask UA to store an unknown media type. Concrete proposal: In 3.1. Error Handling, change # Unknown media types. Unknown media types evaluate to false. # Effectively, they are treated identically to known media types that # do not match the media type of the device. to (be more clarified) | Unknown media types. Unknown media types evaluate to false. | Effectively, they are treated identically to known media types that | do not match the media type of the device, which means that a UA | must store an unknown media type so that it is accessible via | CSSOM. C. Make it undefined. (I think an explicit un</pre> Kang-Hao (Kenny) Lu 2012-05-22T21:36:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.css.general