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/Archives/Public/www-style/2012May/0913.html </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 as the loaded font, you'll never notice the load. This may or may not be okay for the overall sizing (depends on how close the metrics actually are, and thus how much of a coincidence the same-size thing was), but it's definitely bad that it means we have a timer running forever (or until we hit our own timeout). Other fairly advanced apps probably have similar needs. Providing a load event we can listen to instead of polling would be much less fragile, more reliable, and cheaper for the user. Preferably, it would be fired at the &lt; at &gt;font-face rule in the CSSOM, so you don't have to go to any particular effort to figure out which font it was. If you do something more general like firing it at document, you have to provide all the descriptors so you can distinguish separate rules. Thoughts? ~TJ </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;jdaggett&gt; font-family: [[&lt;family-name&gt; | &lt;generic-family&gt;] [, &lt;family-name&gt;| &lt;generic-family&gt;]* ] | inherit &lt;jdaggett&gt; &lt;family-name&gt; == [ &lt;string&gt; | ident+ ] &lt;jdaggett&gt; &lt;generic-family&gt; == [ sans-serif | serif | cursive | fantasy | monospace ] jdaggett: there is a slight ambiguity in the current grammar for font-family names jdaggett: in the current grammar reserved keywords can be matched either as keywords or a sequence of identifiers &lt;jdaggett&gt; http://www.w3.org/TR/CSS21/fonts.html#font-family-prop jdaggett: in the paragraph linked above, keywords are required to be quoted to match the family name type jdaggett: so if you have an unquoted font name that includes inherit or initial it would have to be dropped jdaggett: there is some confusion across browsers. foo inherit can be valid while inherit foo might not be (or vice-versa) jdaggett: I propose we tweak the grammar and change the prose jdaggett: we should allow names like 'inherit foo' but inherit, foo would be invalid florian: I haven't looked at your grammar change but I'm comfortable allowing names such as 'inherit foo' tabatkins: I'm ok with that as well jdaggett: anyone else has objections? jdaggett: one change involves fixing the syntax jdaggett: second change is a rewording jdaggett: both for the CSS2.1 errata &lt;jdaggett&gt; http://lists.w3.org/Archives/Public/www-style/2012May/0630.html (both changes described in the post linked above) some discussion of wording &lt;fantasai&gt; s/are not allowed to/do not/ &lt;fantasai&gt; otherwise, it's ok &lt;bradk&gt; reserved keyword if separated by comma, not if separated with space. Unless quoted. &lt;Bert&gt; (I proposed a note as an alternative to jdaggett's text, maybe that addresses Anton's concern?) &lt;glazou&gt; Bert: please copy here ? &lt;Bert&gt; (My proposed note: "Note that 'font-family: Times, inherit' is therefore an invalid declaration, because 'inherit' in that position can neither be a valid keyword nor a valid font family name.") jdaggett: this is not the best language. I'm only trying to make the most important change i.e. identify initial, inherit and default as not being magic family names dbaron: I just realized we want unquoted default inherit and initial to not match &lt;family-name&gt; dbaron: but I'm not sure the proposed language says that glazou: are folks ok with the change, modulo final language? RESOLVED: John's proposal to resolve the issue is accepted, exact wording to be settled on list ACTION jdaggett to finalize errata language &lt;trackbot&gt; Created ACTION-474 &lt;jdaggett&gt; proposed wording for CSS 2.1 errata related to unquoted font family names: &lt;jdaggett&gt; http://lists.w3.org/Archives/Public/www-style/2012May/0852.html Flexbox ------- &lt;fantasai&gt; http://wiki.csswg.org/topics &lt;glazou&gt; http://wiki.csswg.org/topics?datasrt=&amp;dataflt[]=spec%3Dcss3-flexbox tabatkins: we must resolve naming issues first so as to freeze the API &lt;fantasai&gt; http://wiki.csswg.org/topics/alignment-names tabatkins: first renaming alignment properties to generic names tabatkins: this derives from fantasai's css3-align proposal tabatkins: I'm ok with that fantasai: we already have a resolution on this, just need to settle on exact the names tabatkins: let the bikeshedding begin fantasai: do we prefer justify-items or justify-default? fantasai: a lot of people thought default was really vague so let's drop it szilles: what does items mean? &lt;dbaron&gt; I actually like default-* tabatkins: it is the default alignment for flex items szilles: so why is default a bad choice? tabatkins: it's not clear what is being defaulted * sylvaing thinks justify-all-the-things would be fine pcupp: in grid layout we operate on items just like flexbox does on flexbox items ... pcupp: I don't see the use case for having the item-alignment property, why not style the elements directly Tab: anonymous items, and it's just easier pcupp: Anonymous content seems more of an error case than something intentional &lt;dbaron&gt; Was there a reason "child" wasn't considered as an alternative to "item" or "default"? &lt;fantasai&gt; dbaron, grid items it's not the child always glazou: any objection? RESOLVED: eliminate default as a naming option More discussion of various alignment choices. Straw poll... Set 1: Box/Content/Default +--------X----------------Y------ A | box-justify box-align B | content-justify content-align C | default-justify default-align Set 2: Self/Content/Item +--------X----------------Y------ A | self-justify self-align B | content-justify content-align C | item-justify item-align Set 3: Outside/Inside/Items +--------X----------------Y------ A | justify-outside align-outside B | justify-inside align-inside C | justify-items align-items Set 4: Self/Content/Items Inversion +--------X----------------Y------ A | justify-self align-self B | justify-content align-content C | justify-items align-items Set 5: Self/Content/Items Inline/Stack +--------X----------------Y------ A | align-self-inline align-self-stack B | align-content-inline align-content-stack C | align-items-inline align-items-stack plinss: abstain glenn: 2 glazou: abstain sylvaing: abstain antonp: 2,4 jdaggett: abstain florian: 5 rossen: 4 rbetts: abstain johnjansen: 4 arronei: 4 bradk: 5 tabatkins: 4,2 smfr: 4 (don't like term 'stack') dbaron: my preference order is 2 [big gap here] 4 3 5 szilles: 2 or 4. do not like 5 bert: abstain &lt;bradk&gt; I don't like "justify" to mean "align x" fantasai: my favorite is 4. I'm OK with anything that is not 1 hober: abstain RESOLVED: option 4 pcupp: and the intent is to apply those names to grid as well tabatkins: yes fantasai: that was our resolution as the f2f &lt;TabAtkins_&gt; http://wiki.csswg.org/topics/justification-keywords tabatkins: for flex-pack properties there are two values that mean 'spread the items out' tabatkins: in one case the items at either end are flush, in the other they're evenly distributed in the container tabatkins: justify for flushing, distribute for even spacing glazou: why don't we use the names you have there? glazou: edges-flush and equal-margins glazou: that's readable &lt;sylvaing&gt; +1 to glazou &lt;rbetts&gt; +1 to glazou fantasai: my concern is they make no sense when you don't already have the context "we're spacing things out" antonp: is there any reason why equal spacing is not part of flexbox fantasai: no one asked for it inside-flush? szilles: distribute-items/distribute-space? szilles: based on ruby align glazou: no-margins? &lt;fantasai&gt; justify-content: no-margins ???? Does not make sense. szilles: distribute-space maps to equal-margins * bradk thinks that 'justify' should be a value that means what it does in 'text-align'. Confusing to have it as alignment property name. tabatkins: my objection is that this really aligns margin boxes i.e. it distributes space between the margins * antonp likes szilles' way of looking at it fill/distribute? &lt;Rossen&gt; justify-content: between | spread florian: if we can't agree on anything better than what's there, let's keep it rossen: +1 dbaron: I think it's reasonable to give long names to those that add space at the edges since it's something we haven't had before tabatkins: it's a common usage pattern done with margins so far &lt;fantasai&gt; distribute-between | distribute-around &lt;fantasai&gt; ? glazou: this is difficult to straw-poll because we have discussed more proposals than what's on the wiki szilles: can we straw poll between 0 or something new? fantasai: how about distribute-between/distribute-around? &lt;fantasai&gt; space-between | space-around &lt;Rossen&gt; Like! dbaron: I'm confused as to whether you're trying to assign 2 or 3 names &lt;rbetts&gt; makes sense to me tabatkins: only two, we don't include the full space on each side scenario &lt;SteveZ&gt; +1 for space-between and space-around &lt;fantasai&gt; space-between | space-around | space-evenly glazou: straw poll between option 0 and space-around/space-between plinss: abstain glazou: 0 sylvaing: 0 antonp: 1 jdaggett: abstain glenn: 0 florian: abstain arronei: abstain fantasai: 1 rossen: 0 then 1 johnjansen: 0 tabatkins: 1 dbaron: abstain (though I might prefer splitting the difference, justify/space-?) bradk: 0 szilles: 1 bert: 1 rbetts: 1 hober: abstain RESOLVED: use space-between/space-around instead of justify/distribute &lt;fantasai&gt; http://wiki.csswg.org/topics/css3-flexbox-rename-flex-order tabatkins: next, renaming the flex-order property tabatkins: grid layout's auto placement is similar to flexbox's algorithm so we think there should be a common property: display-order fantasai: also, this property has nothing to do with flexing dbaron: this may be a bit confusing given the display property and display-inside/display-outside dbaron: box-order? szilles: this reorder the items so item-order? bradk: just order! dbaron: item-order bad since we just made "item" something that applies to children rather than self szilles: I'm concerned about box-order if this property is to apply to region flows rossen: when you have multiple boxes for elements, do all the boxes have the same order fantasai: it works like z-index -- boxes with the same index are subsorted by document order &lt;rbetts&gt; +1 to just "order" as proposal D pcupp: what other ordering is affected? if you re-order input element does the tab order move around? tabatkins: at the moment no, tab order comes from document order straw poll A = flex-order B = box-order C = display-order D = order plinss: D, then B glazou: D, then B sylvaing: abstain antonp: not A jdaggett: abstain glenn: abstain florian: B or D, not A fantasai: not A johnjansen: abstain rossen: B arronei: abstain dbaron: D, then B tabatkins: D, C, B bradk: D then B szilles: D, C, B bert: abstain rbetts: D hober: abstain &lt;Bert&gt; (Steven Pemberton once proposed a 'something-order' property to reorder children, independent of the display model, like a generic transformation.) RESOLVED: rename flex-order to order &lt;antonp&gt; D both pleases and scares me TabAtkins: Last one for next week: &lt;TabAtkins&gt; http://wiki.csswg.org/topics/start-end-before-after-align Meeting closed. </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, and make align-* use "before" and "after". The argument for (1) is that, first, using different keywords to accomplish basically the same thing in two properties is confusing, and second, these aren't the logical axises. I *actually* call the directions "main-start/end" and "cross-start/end" in the Flexbox spec, and just drop the prefix for brevity in the property value. The argument for (2) is that, first, using the same keyword in different axises is confusing, and second, while they're not an exact match for the logical keywords in Flexbox, they *are* in Grid and probably Block, as both of those always lay out relative to the current writing mode. You'll note that the first arguments for both are directly contradictory. I think that means this is more of a personal choice thing. Anyway, I have no strong opinions, but I want to resolve this in the next week. If we can't come to an agreement on the mailing list, I'll ask for a quick poll at the beginning of the next telcon. So, get all your arguments in now and decide this among yourselves. ~TJ </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. Perhaps the browser is trying to "equalize the text wrapping margins" or something like that, but that would just be guessing. And also, if that were true, you'd think the browser would displace more text than it did in the 100px right padding example. Anyway I've looked in section 9.4.2 and elsewhere in the spec, but there doesn't seem to be an explanation. Thank you </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 - Media Queries level 4: discussion ideas and direction for the next level of the spec - Spec stylesheet - Use of alternate stylesheet - Changing default font - CSS3 Syntax - Parsing scientific notation in CSS &lt;/Daniel&gt; </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 automatically if I just state "as specified". And if it doesn't happen automatically, whether all SVG properties ought to be computing &lt;length&gt;s down to absolute lengths. Thanks, Cameron </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 developers are, too. Webkit has a method called `void scrollIntoViewIfNeeded(optional boolean center);`, which scrolls the page so that an element, if not completely shown, becomes completely shown, and appears vertically centered in the viewport if the boolean is true. The reason I bring this method up is to highlight its bad design. 1. Boolean flags are unreadable: it is unclear from reading `scrollIntoViewIfNeeded(false)` what that `false` means, and even if we know that it is about centering the element, which one, of `true` and `false`, does indeed center the element. 2. We already have `void scrollIntoView(optional boolean top)`. Having many methods whose intents are collinear is wrong. Different methods should have orthogonal goals. I therefore suggest the following addition: partial interface Element { void scrollIntoView(ScrollPosition options); }; dictionary ScrollPosition { float top = 0.5; float left = 0.0; boolean notIfViewed = true; }; where `top` and `left` are meant as percentages of `max(0, scrollY - element.clientHeight)` and `max(0, scrollX - element.clientWidth)` respectively. If `notIfViewed` is true, and the element is completely in the viewport, then this method does nothing. If `notIfViewed` is true, and the element is partially hidden, then scroll just enough so that the element appears completely in the viewport. In all other cases, scroll so that the element is positioned at `options.top * max(0, scrollY - element.clientHeight)` with respect to the top border edge, and at `options.left * max(0, scrollX - element.clientWidth)` with respect to the left border edge. Overloading of `scrollIntoView` happens as described at &lt;http://www.w3.org/TR/WebIDL/#idl-overloading&gt;. An intended effect of this design is that calling `element.scrollIntoView({});` automatically does the right thing and centers the element on the screen, while you can still get the old behavior by calling `element.scrollIntoView()`. </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 undefined is usually better than saying nothing at all.) Just in case we want a "mixed approach", these are all the media types IE9 recognizes: ‘aural’, ‘braille’, ‘handheld’, ‘print’, ‘projection’, ‘screen’, ‘tty’, ‘tv’ and ‘embossed’. Or in other words, all the media types listed in css3-mediaqueries besides 'speech'. Cheers, Kenny </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