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/45007 <pre>John Daggett &lt;jdaggett&lt; at &gt;mozilla.com&gt; wrote on 2013/05/16 12:18:54 I have the same opinion with John. Synthetic italics should be consistent with real italics. I understand some of Koji's concern about this behavior but I believe this is the most better choice: "#2 Top edge to right" (in upright orientation): http://koji.ec/archives/32 | #2 Top edge to right is one way to implement naturally. If an | implementation renders a glyph in upright in vertical flow, | existing code will slant the top edge to right, so this behavior | requires the least work for such implementations. But this is | the only case where slant is applied orthgonally to the baseline, | which poses some issues such as: | | 1. Characters will overlap with underlines if drawn on right. | 2. Ruby and emphasis marks will not align if slanted together, or | overlap with base characters if they don’t. How to handle such cases | need to be determined. | If we want to slant ruby in the same way as the base character, | UA ne</pre> MURAKAMI Shinyu 2013-05-18T04:45:34 http://permalink.gmane.org/gmane.comp.web.css.general/45006 <pre> I don't think we resolved on this yet, and I changed my mind because of an argument given by email after the last conf call discussion. (I can't find the reference right now, sorry.) That is, lifting this restriction on ID selectors would be nice but it's more important that they are consistent with class selectors, which are definitely delim(.) + ident. Lifting the restriction on class selectors too would mean dealing with number and dimension tokens, let's not go there. </pre> Simon Sapin 2013-05-18T01:52:54 http://permalink.gmane.org/gmane.comp.web.css.general/45005 <pre> Excellent, thanks! A small section would suffice. Could you just try rewriting the number/percentage/dimension parsing? That's probably the most complex set of interlocking states. I don't have a problem with the former. Done. Yeah, I guess you're right. Removed. Hm, interesting. I support using some sort of delimiter, and those angle brackets look pretty good. This'll be a good bit of work to do. ^_^ Why? Propably implicit, but I've gone ahead and specified it. Not yet! I'm supposed to be doing a google-data search to find hashes in selectors that aren't valid idents. As long as I don't find anything damning, though, we are dropping the distinction. The parser in Syntax ended up only accepting valid unicode ranges (except that it does, technically, allow for ranges where the min is higher than the max). This is more restrictive than CSS 2.1, but it only fails to cover things that were invalid in the first place. Added, thanks. I'm comfortable with either doing it now, or waiti</pre> Tab Atkins Jr. 2013-05-17T20:16:22 http://permalink.gmane.org/gmane.comp.web.css.general/45004 <pre>On Fri, 17 May 2013 21:40:08 +0200, Tab Atkins Jr. &lt;jackalmage&lt; at &gt;gmail.com&gt; wrote: Right, this resolution is compatible with the specs as they are. At the same time, while nothing is necessary strictly speaking, I do think a note would be welcome. The fact that the WG had to debate it shows that it is not entirely obvious, and both authors and implementors might miss the implication. V&amp;U seems the best host for this note. - Florian </pre> Florian Rivoal 2013-05-17T19:46:05 http://permalink.gmane.org/gmane.comp.web.css.general/45003 <pre> Nothing needs to be changed anywhere - this resolution is just in line with what the specs already say. MQ's token-based syntax just defers to "expr", which covers calc(), and the individual MQs use property grammar productions like &lt;length&gt;, which include the appropriate calc()s. ~TJ </pre> Tab Atkins Jr. 2013-05-17T19:40:08 http://permalink.gmane.org/gmane.comp.web.css.general/45002 <pre>On Tue, 14 May 2013 09:29:31 +0200, Tab Atkins Jr. &lt;jackalmage&lt; at &gt;gmail.com&gt; wrote: Divergence between vendors is not going to be nice for authors, so having a clear discussion and hopefully a resolution at the WG level would certainly be nice. It is not going to force anybody to do anything, but it may nudge everyone in the same direction. In general, I like the direction Firefox and Chrome are taking, and we should try to formalize it. Fantasai and I had started working on an attempt at writing up something similar right after the original discussion happened, but since the WG's attention moved somewhere else, it kind of died out. If we are reopening the topic, I'd be happy to dig it out, clean it up, and see if we can use that to build upon. - Florian </pre> Florian Rivoal 2013-05-17T19:37:48 http://permalink.gmane.org/gmane.comp.web.css.general/45001 <pre> Should this be specified in the MQ spec, or can it be done in the Values and Unitsspec only? Since V&amp;U introduces it by saying: "It can be used wherever &lt;length&gt;, &lt;frequency&gt;, &lt;angle&gt;, &lt;time&gt;, &lt;number&gt;, or &lt;integer&gt; values are allowed." I suppose it just needs a clarification there, and no change is needed in the MQ spec. Do we agree on that? - Florian </pre> Florian Rivoal 2013-05-17T19:15:38 http://permalink.gmane.org/gmane.comp.web.css.general/45000 <pre> On a another note, I don't like the fact the selector is an argument sitting inside a parenthesis of ::distributed/::region because it implies something else can follow the selector. For example, doing "someElement::after:hover" or "someElement::scrollbar-track:hover" could make sense but "someElement::region(&gt;*):hover" does not. I still believe we need something that looks more like a combinator than a pseudo-element here. someElement ...&gt; * someElement ...&gt; *:hover I know it has been rejected because (a...b) matches elements that b does not necessarily but I really believe this is not a big issue and it makes much more sense than using ::region(*) and ::distributed(*) while both actually just represent a selection function the same way any other combinator does if you think left to right, which --all your CSS users-- do. Also, it's shorter to write if we have nesting: someElement { abc: def; abc: def; &lt; at &gt;then ...&gt; strong { a</pre> François REMY 2013-05-17T19:09:18 http://permalink.gmane.org/gmane.comp.web.css.general/44999 <pre> I plan to go through this draft line-by-line on Sunday, when I have a long plane flight. Here are some high-level points for now. I see that I never responded to your response to my critique of the February draft -- sorry about that. I'll start with things that are dangling threads from then: * Regarding the comments-in-SVG-presentation-attrs thing, I'm happy to leave this out of the spec unless and until the SVG WG decides they're *not* going to allow comments. * Regarding recursive-descent-style tokenization and removal of pushback, you were skeptical that this would be easier to read. Would you be interested in me attempting to rewrite section 4 with those changes, to see how it goes? It would be pretty major so I don't want to do it if you're not at least curious whether it would be better. * 3.2.1 "Preprocessing the input stream": I still think that *either* FORM FEED should be converted to LINE FEED here, *or* all four possible newline sequences (LF, CR, CR LF, and F</pre> Zack Weinberg 2013-05-17T18:12:29 http://permalink.gmane.org/gmane.comp.web.css.general/44998 <pre> While I agree with you that the grouping allowed by &lt; at &gt;region was good (we've received feedback that the repetition required to use ::distributed() isn't great either), I'd rather solve it generically by reworking my Hierarchies (Nesting Rules) draft. In other words, I support keeping ::region(), and then working on a generic nesting solution that'll fix the repetition. ~TJ </pre> Tab Atkins Jr. 2013-05-17T17:34:59 http://permalink.gmane.org/gmane.comp.web.css.general/44997 <pre> I think this is the crux of the issue. When an author says to use an italic face they assume that an italic font or an oblique font depending on the font family. In the absense of an italic or oblique font, the user agent ghats the instruction to use an italic font as a instruction to synthesise an oblique font where the glyphs are distorted/transformed to attempt to give the appearance of an oblique font. This transformation would visually appear to be a transformation from the baseline. And my gut reaction is that it is a transformation that is only relevant to a limited number of scripts. There is a long history of word processing and text manipulation that has misused the term italic and it has been applied to scripts where it doesn't apply or doesn't belong. Japanese users have been exposed to this synthetic usage. And I agree that what Koji is refering to neither italisising or obliquing. But then the same distinction to most of the Unicode repetitoire Partly we are discussing a confusion of</pre> Andrew Cunningham 2013-05-17T08:17:58 http://permalink.gmane.org/gmane.comp.web.css.general/44996 <pre> fantasai wrote: Um, it's not reset by the font shorthand... Maybe you're not parsing "font feature properties" correctly? I guess it would make sense to give a more specific list to reduce the chance for confusion like this. I don't think this is quite right, 'font-size-adjust' usage makes sense for small body text but less so for display text or body text that of a "large enough" size. So I don't think it's blanket use for all elements on a page is something to be recommended. It's not part of the 'font' shorthand but it is reset by the font shorthand. Regards, John </pre> John Daggett 2013-05-17T07:20:32 http://permalink.gmane.org/gmane.comp.web.css.general/44995 <pre> fantasai wrote: It's generally the height of glyphs and I don't think changing this to "size" adds an clarity to the spec. This is the same text that is used in 2.1. The definition of value units belongs in the Values spec, no? Cheers, John </pre> John Daggett 2013-05-17T07:00:10 http://permalink.gmane.org/gmane.comp.web.css.general/44994 <pre> fantasai wrote: Nope, that's not what I mean. ;) It is monotonic but the point is that the scale is not absolute, it's up to the type designer to decide what's expanded vs. semi-expanded. Cheers, John </pre> John Daggett 2013-05-17T06:29:06 http://permalink.gmane.org/gmane.comp.web.css.general/44993 <pre> Hi Koji, talking about is the use case for Japanese obliquing (斜体、shatai). Yet what you're proposing is a modification to the behavior of 'font-style: italic'. What I and others have been saying is that Japanese shatai should not be equated with italics, they are different features and the usage patterns are quite distinct, even though they overlap because some form of obliquing may be involved. To put it another way, when an author says "use an italic font" they are not saying "oblique this text", even though the end result may be the same sometimes. That's a fair summary. I think my viewpoint has evolved from simply thinking the change you're proposing wasn't really important since italics are rarely used in vertical text to the realization that the mechanism you're proposing is a very poor match for the select set of use cases that exist in practice and that the correct parameterization of Japanese obliquing is complex enough that it warrants a separate property. Is your thinking that twea</pre> John Daggett 2013-05-17T06:19:02 http://permalink.gmane.org/gmane.comp.web.css.general/44992 <pre> Ah, well no wonder you didn't think it was hugely more readable. I was thinking it was '&lt; at &gt;flow' followed by the name of the flow, similar to &lt; at &gt;page and named pages. But I guess that wouldn't work, since more than one element can receive the same named flow. Hmm. I guess regions doesn't have the equivalent of css3 page's named pages, or a 'region' property to jump flow content to a particular named region, but maybe it should. Anyway, the rest of my argument stands. I still think &lt; at &gt;region is more elegant and readable and writable, without resorting to workarounds for the inherent problems of the pseudo-element approach, workarounds which can't really give it enough help to restore the original simplicity and elegance of the &lt; at &gt;rule approach. </pre> Brad Kemper 2013-05-17T03:29:20 http://permalink.gmane.org/gmane.comp.web.css.general/44991 <pre>Hey all, I've checked in two editor's drafts of the new modules (CSS Exclusions and CSS Shapes) that used to share a single draft: http://dev.w3.org/csswg/css-exclusions/ http://dev.w3.org/csswg/css-shapes/ The CSS Shapes draft includes just the shape-outside properties relevant to floats, along with shape values from Basic Shapes and image URLs. The intent is to have shape-inside and referencing SVG elements defined in a future level of CSS Shapes. Both drafts have notes mentioning that if a UA implements both CSS Exclusions and CSS Shapes, then the shape defined by shape-outside determines the exclusion area of an element. This will become normative text in one of these drafts depending on how the drafts progress through the process. Thanks, Alan </pre> Alan Stearns 2013-05-17T00:35:17 http://permalink.gmane.org/gmane.comp.web.css.general/44990 <pre>I don't think font-synthesis should be reset by the font shorthand. It's typically something you want to set once at the top of the document, and allow to inherit through the whole thing. The 'font-size-adjust' property has a similar usage pattern, especially wrt the 'auto' value. Since other values might be less like that, I can see an argument for resetting it in the shorthand. However, if we think it should be reset nonetheless, that fact should be pointed out in a note in the 'font-size-adjust' property, and a good practice example for using 'auto' included. Maybe | In this example, the 'auto' value is used to equalize | x-heights across fonts of the same nominal size: | * { font-size-adjust: auto; } | Notice the universal selector: the property inherits, but | because it is reset by the 'font' shorthand, it must be | set on every element to reliably take effect across the whole | document. note that as a side-effect, this rule effectively | disables inheritance of 'font-size-</pre> fantasai 2013-05-16T23:50:16 http://permalink.gmane.org/gmane.comp.web.css.general/44989 <pre>http://dev.w3.org/csswg/css-fonts/#font-size-adjust-prop # 3.6 Relative sizing: the font-size-adjust property Suggest calling this "X-height sizing", since that better explains what it really does. # This property allows authors to specify an aspect # value for an element that will effectively preserve # the x-height of the first choice font, whether it is # substituted or not. This doesn't seem like a very accurate description of the property. It only preserves the x-height of the first choice font if you specify that font's x-height as its value. Maybe, taking a cue from dbaron, something like | This property allows equalizing font sizes by ex-height | rather than em-height. ? # Authors can use this value to specify that font size # should be normalized across fonts based on the x-height # without the need to specify the aspect ratio explicitly. Suggest s/based onthe x-height/by matching their x-heights/ ? http://dev.w3.org/csswg/css-fonts/#font-prop # The ‘font’ prope</pre> fantasai 2013-05-16T23:43:09 http://permalink.gmane.org/gmane.comp.web.css.general/44988 <pre>While we're on the subject of font-size-adjust, there has earlier been acknowledgement that this property is very Latin-centric, and is inadequate as a general mechanism for size adjustments of fonts for scripts that do not have an x-height notion equivalent to that of Latin. Is anyone interested in discussing ideas for a more general mechanism that could be applied to other writing systems? JH </pre> John Hudson 2013-05-16T22:49:54 http://permalink.gmane.org/gmane.comp.web.css.general/44987 <pre>http://dev.w3.org/csswg/css-fonts/#font-size-prop # This property indicates the desired height of glyphs from the font. Shouldn't that be "desired size"? Because in vertical typesetting with proportional or non-square glyphs, it's not necessarily the height. # A &lt;relative-size&gt; keyword is interpreted relative to the table # of font sizes and the font size of the parent element. I'd tighten this up to "and the computed 'font-size' of the parent". # A length value specifies an absolute font size (that is independent # of the user agent's font table). s/that is// # The following table provides user agent's guideline This is non-grammatical... more like Engrish. # avoid creating font-size resulting in less than 9 pixels s/pixels/device pixels/ because we have too many pixels in CSS... *** The following is a substantive issue. *** # The actual value of this property may differ from the computed # value due a numerical value on ‘font-size-adjust’ and the # unavailabilit</pre> fantasai 2013-05-16T22:44:50 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.css.general