Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

{comment}

100 messages.

Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Sat, 19 Apr 2014 20:40:20 +0000

www-style > April 2014 > 0000.html

Received on Saturday, 19 April 2014 20:40:57 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

> > 3. The only place the spec mentions that text-transform should > > affect line breaking is in an informative example (#2), at least > > that I saw. Should this be mentioned in a normative section? Some > > line breaking changes are obvious (for instance, changing the > > width of the glyphs will alter line breaking), but others are > > more obscure (for instance, transformation to full width). > > This is implied by the ordering in Appendix A: > http://dev.w3.org/csswg/css-text/#order > > However I can add a note to clarify that point to the text-transform > section. Fixed. /koji
Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Sun, 20 Apr 2014 08:19:14 +0000

www-style > April 2014 > 0000.html

Received on Sunday, 20 April 2014 08:19:47 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

> > 4. From 5.1, last bullet point: > > "For line breaking in/around ruby, [...] > > However, I would expect the correct breaking would be neither of those, but rather: > > だ[1]大分[3]日数[5]が > > I am not certain how I can interpret the spec to generate those line breaks. > > Good point. This sentence was written before we had a reasonable > draft of the ruby spec to refer to, so I will replace this with > a pointer to that spec, which has a much more involved discussion > of ruby line-breaking: > > http://www.w3.org/TR/css-ruby-1/#line-breaks > > I'll drop a link to the updated text once I get in the edits. :) Fixed. /koji
Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Sun, 20 Apr 2014 08:40:48 +0000

www-style > April 2014 > 0000.html

Received on Sunday, 20 April 2014 08:41:21 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

> > 5. In "5.2. Breaking Rules for Punctuation", in this sentence > > and the one below it that is similar: > > "If the content language is Chinese or Japanese, then additionally > > allow (but otherwise forbid) for ‘normal’ and ‘loose’:" > > It's not clear to me what the 'otherwise' applies to - is it the > > 'normal' and 'loose', so it is forbidden in strict when the language > > is Chinese or Japanese? Or does it apply to the language as well, > > so it is forbidden in strict for Chinese and Japanese, and for any > > value for all other languages? If the latter, then the implication > > is that in eg English, breaks before U+2010 are forbidden. However, > > the later clarifying note seems to indicate that non-CJK text is > > only affected when the language is Chinese or Japanese. > > It applies to "is Chinese or Japanese", so it would be > If the content language is Chinese or Japanese then allow [...] > If the content language is not Chinese or Japanese then forbid [...] Re-worded to make the original intention clearer, though, this definition seems to have other issues[1] if the “otherwise" applies to “is Chinese or Japanese.” I’ll continue the discussion in the thread. [1] http://www.w3.org/mid/3EE56732-602B-4304-9817-E18A1F6EBCE8@gluesoft.co.jp /koji
Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Sun, 20 Apr 2014 08:55:42 +0000

www-style > April 2014 > 0000.html

Received on Sunday, 20 April 2014 08:56:18 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

> > 6. In "6.1. Hyphenation Control", the sentence: "The UA is therefore > > only required to automatically hyphenate text for which [...]" > > Is it the case that a UA is ever *required* to automatically hyphenate? > > I believe not. Not sure if the comment suggests re-wording, nor could I found good re-wording. If you think the text is misleading, could you suggest re-wording? If otherwise, I’ll consider this as closed. /koji
Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Sun, 20 Apr 2014 10:05:55 +0000

www-style > April 2014 > 0000.html

Received on Sunday, 20 April 2014 10:06:30 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

I missed that the comment #6 actually contains 3 feedbacks, so going through the other 2: >> 6. In "6.1. Hyphenation Control", the sentence: "The UA is therefore >> only required to automatically hyphenate text for which [...]" >> Is it the case that a UA is ever *required* to automatically hyphenate? > > I believe not. Not sure if the comment suggests re-wording, nor could I found good re-wording. If you think the text is misleading, could you suggest re-wording? If otherwise, I’ll consider this as closed. > > Perhaps this should be weakened to "Therefore, if no language is > > specified or no hyphenation resource is available to the UA for a > > specified language, the UA may choose to treat 'auto' as 'manual'." > > > > Section 6.1 also states, "Conditional hyphenation characters inside > > a word, if present, take priority over automatic resources when > > determining hyphenation opportunities within the word." Is this a > > strong-enough statement? We've seen many cases where a word will > > hyphenate one character away from a soft hyphen. > > Hm, interesting. I'll update the text to say that automatic hyphenation > points within the word are ignored when it contains ­ Fixed. > > 6.1 In example 8, there is an extra nun in نوشتنن, at the end. I > > think it should be نوشتن. > > Fixed. /koji
Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Sun, 20 Apr 2014 13:16:40 +0000

www-style > April 2014 > 0000.html

Received on Sunday, 20 April 2014 13:17:16 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

> > 15. In "8.2. Tracking", just after example 14: "[...] to the > > innermost element element that contains the two characters [...]" > > Just one element? > > Yes. Why? I guess it points out that “element element” should be one “element”. Fixed. /koji
[css-values] Comments on section 5.2 and 9
Momdo Nakamura   Tue, 29 Apr 2014 04:16:10 +0000

www-style > May 2014 > 0000.html

Received on Tuesday, 13 May 2014 16:12:04 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org
Copied to: comm@makotom.org.

Hello, I have two comments about section 5.2 and 9 in Editor's Draft. 1) section 5.2 The original text says > The image below illustrates the effect of viewing distance on the size of a reference pixel: > a reading distance of 71 cm (28 inches) results in a reference pixel of 0.26 mm, while a reading > distance of 3.5 m (12 feet) results in a reference pixel of 1.3 mm. but Figure 1 shows '0.28 mm' and '1.4 mm'. Is Fufure 1 really correct? 2) section 9 This Editor's Draft refers to draft-ietf-appsawg-about-uri-scheme-07, but we know RFC 6694 is now published. Best Regards, NAKAMURA, momdo
[css-variables] Author comments reported by Daniel (was: Agenda conf call 07-may-2014)
François REMY   Wed, 7 May 2014 12:44:30 +0200

www-style > May 2014 > 0000.html

Received on Wednesday, 7 May 2014 10:44:57 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: daniel.glazman@disruptive-innovations.com
Copied to: www-style@w3.org.

Hi Daniel, > Before our call later today, I would like to forward here verbatim > comments from css authors I recently met and had a long chat with: > > 2. (unrelated to the agenda item above) the -- prefix for Custom > Properties is ugly and unreadable, also prone to errors. (and > I will not tell you their precise words here, ahem...) This is interesting. Could you clarify what the author meant? I've two questions here: what is considered ugly, and why? Are there "logical" (too much to type, ...) or "cognitive" (we taught us not to use that, this reminded me <x> but wasn't similar, ...) reasons behind this, or is that merely an opinion? I agree that "width: calc(var(--grid-col-span, 1) * var(--grid-col-size, 0px))" has too much non-meaningful tokens (and could be thought as inelegant) and always claimed we should allow "width: --grid-col-size" and "width: calc((--grid-col-span||1) * (--grid-col-size||0px))" in future revisions of the spec, but I don't think "--custom-property: value" is ugly by any mean. Double-dash never was my preference but this is a very good compromise, I think. Changing that would require valid arguments and not mere opinions, I guess. > I tend to agree with both opinions. Is that a change from your initial position [0] which was that "--" looked ok? What made you change your mind, if you can coin that? Best regards, François ________________________ [0] http://lists.w3.org/Archives/Public/www-style/2014Mar/0351.html
Re: [css-values] Comments on section 5.2 and 9
Simon Sapin   Wed, 21 May 2014 15:27:43 +0100

www-style > May 2014 > 0000.html

Received on Wednesday, 21 May 2014 14:28:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: xmomdo@gmail.com, www-style@w3.org
Copied to: comm@makotom.org.

On 29/04/2014 05:16, Momdo Nakamura wrote: > Hello, > > I have two comments about section 5.2 and 9 in Editor's Draft. > > 1) section 5.2 > The original text says >> The image below illustrates the effect of viewing distance on the >> size of a reference pixel: a reading distance of 71 cm (28 inches) >> results in a reference pixel of 0.26 mm, while a reading distance >> of 3.5 m (12 feet) results in a reference pixel of 1.3 mm. > > but Figure 1 shows '0.28 mm' and '1.4 mm'. Is Fufure 1 really > correct? Starting from "96dpi at 28 inches distance", I double-checked the other numbers and fixed the picture. It is indeed 0.26mm and 1.3mm. > 2) section 9 > This Editor's Draft refers to draft-ietf-appsawg-about-uri-scheme-07, > but we know RFC 6694 is now published. Fixed. Thanks! -- Simon Sapin
[css-flexbox] PF comment on Flexbox: Advise authors about reordering
Michael Cooper   Wed, 21 May 2014 12:48:27 -0400

www-style > May 2014 > 0000.html

Received on Wednesday, 21 May 2014 16:48:33 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org
Copied to: wai-liaison@w3.org.

Below is a review from the Protocols and Formats Working Group on CSS 3 Flexbox <http://www.w3.org/TR/2014/WD-css-flexbox-1-20140325/>. <blockquote> 5.4.1 Reordering and Accessibility The order property does not affect ordering in non-visual media (such as speech). Likewise, order does not affect the default traversal order of sequential navigation modes (such as cycling through links, see e.g. nav-index [CSS3UI] or tabindex [HTML40]). Authors must use order only for visual, not logical, reordering of content; style sheets that use order to perform logical reordering are non-conforming. This is so that non-visual media and non-CSS UAs, which typically present content linearly, can rely on a logical source order, while order is used to tailor the visual order. (Since visual perception is two-dimensional and non-linear, the desired visual order is not always logical.) </blockquote> The reordering and accessibility section mentions tabindex and nav-index. However, it's not quite strong enough on the importance of focus order for visual keyboard users. We suggest to add "authors who change the order using order, flex-direction=row-reverse, flex-direction=column-reverse, or flex-flow (and ??) must|should adjust the focus order with either nav-index or tabindex."
Re: [css-flexbox] PF comment on Flexbox: Advise authors about reordering
fantasai   Wed, 21 May 2014 18:53:44 -0700

www-style > May 2014 > 0000.html

Received on Thursday, 22 May 2014 01:54:24 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 05/21/2014 09:48 AM, Michael Cooper wrote: > Below is a review from the Protocols and Formats Working Group on CSS 3 Flexbox > <http://www.w3.org/TR/2014/WD-css-flexbox-1-20140325/>. > > <blockquote> > 5.4.1 Reordering and Accessibility > > The order property does not affect ordering in non-visual media (such as speech). Likewise, order does not affect the default > traversal order of sequential navigation modes (such as cycling through links, see e.g. nav-index [CSS3UI] or tabindex > [HTML40]). Authors must use order only for visual, not logical, reordering of content; style sheets that use order to perform > logical reordering are non-conforming. > > This is so that non-visual media and non-CSS UAs, which typically present content linearly, can rely on a logical source > order, while order is used to tailor the visual order. (Since visual perception is two-dimensional and non-linear, the desired > visual order is not always logical.) > </blockquote> > > The reordering and accessibility section mentions tabindex and nav-index. However, it's not quite strong enough on the > importance of focus order for visual keyboard users. > > We suggest to add "authors who change the order using order, flex-direction=row-reverse, flex-direction=column-reverse, or > flex-flow (and ??) must|should adjust the focus order with either nav-index or tabindex." The reason why tabindex and nav-index are not affected by Flexbox reordering is *because* we want the focus order to follow the source order. If the logical order (that speech and focus should follow) needs to be reordered, that should be done at the source level, and not with flex-flow. I think the spec is reasonably clear about this in the section you just quoted. Therefore I am rejecting your suggestion. It is actively harmful. Authors who want such reordering should reorder the source order instead of using flex-flow. ~fantasai
[css-gcpm] Bookmarks comment
Jirka Kosek   Thu, 12 Jun 2014 18:40:47 +0200

www-style > June 2014 > 0000.html

Received on Thursday, 12 June 2014 16:41:19 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

Hi, in http://www.w3.org/TR/2014/WD-css-gcpm-3-20140513/#bookmarks properties for manual bookmark creation are defined. HTML5 defines outline algorithm (http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines) for automatic creation of outline. It would be useful if bookmarks could be created automatically based on an outline as well. Additional property "bookmarks" can be added with values "none", "auto" and "from-bookmark-level". The default should be "auto" which will provide automatic bookmarks based on the document outline. Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------
Re: [css-gcpm] Bookmarks comment
Håkon Wium Lie   Fri, 13 Jun 2014 00:02:09 +0200

www-style > June 2014 > 0000.html

Received on Thursday, 12 June 2014 22:02:40 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jirka@kosek.cz
Copied to: www-style@w3.org.

Jirka Kosek wrote: > in http://www.w3.org/TR/2014/WD-css-gcpm-3-20140513/#bookmarks > properties for manual bookmark creation are defined. HTML5 defines > outline algorithm > (http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines) > for automatic creation of outline. It would be useful if bookmarks could > be created automatically based on an outline as well. > > Additional property "bookmarks" can be added with values "none", "auto" > and "from-bookmark-level". The default should be "auto" which will > provide automatic bookmarks based on the document outline. Your proposed solution could work. I'd be hesitant to add it, though; we have two interoperable implmentations of the currently described functionality [1], and I doubt implementors would prioritize this without requsts from users. [1] http://books.spec.whatwg.org/#bookmarks -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Re: [css-gcpm] Bookmarks comment
Jirka Kosek   Fri, 13 Jun 2014 10:12:58 +0200

www-style > June 2014 > 0000.html

Received on Friday, 13 June 2014 08:13:26 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: howcome@opera.com
Copied to: www-style@w3.org, www-style@w3.org.

On 13.6.2014 0:02, Håkon Wium Lie wrote: > Your proposed solution could work. I'd be hesitant to add it, though; > we have two interoperable implmentations of the currently described > functionality [1], and I doubt implementors would prioritize this > without requsts from users. As a user I would prefer if bookmarks will show up automatically for documents with reasonable structure. > [1] http://books.spec.whatwg.org/#bookmarks Out of curiosity -- how the above cited spec is related to [css-gcpm]? Are they being synchronized regularly? Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------
Re: [css-gcpm] Bookmarks comment
Håkon Wium Lie   Fri, 13 Jun 2014 11:28:21 +0200

www-style > June 2014 > 0000.html

Received on Friday, 13 June 2014 09:28:52 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jirka@kosek.cz
Copied to: www-style@w3.org.

Jirka Kosek wrote: > > Your proposed solution could work. I'd be hesitant to add it, though; > > we have two interoperable implmentations of the currently described > > functionality [1], and I doubt implementors would prioritize this > > without requsts from users. > > As a user I would prefer if bookmarks will show up automatically for > documents with reasonable structure. Agreed. This can be achived by having the rules in the UA style sheet. For example: h1 { bookmark-level: 1 } h2 { bookmark-level: 2 } h3 { bookmark-level: 3 } > > [1] http://books.spec.whatwg.org/#bookmarks > > Out of curiosity -- how the above cited spec is related to [css-gcpm]? > Are they being synchronized regularly? This is the intention of the editors. In the end, implementors decide. -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Re: [css-text] comments from DPub IG (Fwd)
Koji Ishii   Wed, 25 Jun 2014 05:19:38 +0000

www-style > June 2014 > 0000.html

Received on Wednesday, 25 June 2014 05:20:11 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

> > 9. In "7.1. Text Alignment", "text-align: start end" sounds a > > lot like "text-align-last: *", giving special treatment to the > > first line instead of the last line, with less control. Perhaps > > there should be a separate property for controlling the first > > line alignment, just like there is for controlling the last line. > > Then text-align could become a shorthand. For example: > > > > text-align: center == text-align-first: center, > > text-align-middle: center, text-align-last: auto > > [...] > > I think I will re-raise this to the WG, will reply with an update. We discussed this at the Seoul F2F and resolved to defer to Level 4[1]. > - RESOLVED: Defer text-align-first and text-align: start-end > to level 4 Please let us know if any. [1] http://lists.w3.org/Archives/Public/www-style/2014Jun/0167.html /koji
Re: [css-text] 'hanging-punctuation' comments
fantasai   Mon, 21 Jul 2014 06:14:05 -0700

www-style > July 2014 > 0000.html

Received on Monday, 21 July 2014 13:15:19 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: kanghao.lkh@alibaba-inc.com, www-style@w3.org, murakami@antenna.co.jp.

On 11/11/2013 05:23 PM, Kang-Hao (Kenny) Lu wrote: > (2013/11/12 9:07), Kang-Hao (Kenny) Lu wrote: >> # Non-zero start and end borders/padding between a hangeable mark and >> # the edge of the line prevent the mark from hanging. >> >> Why doesn't this include 'margin'? Why about 'text-indent' and floats? > > Nevermind 'text-indent'. [...] Good point. I'm not sure why it should exclude margins. I've added margins to that sentence. Murakami-san, could you please verify if this is correct? :) (As for floats and text-indent, they're not relevant because they're outside of the line box and do not participate in its inline formatting context.) ~fantasai
Re: [css-text] comments from DPub IG (Fwd)
fantasai   Mon, 21 Jul 2014 09:13:20 -0700

www-style > July 2014 > 0000.html

Received on Monday, 21 July 2014 16:14:01 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, public-digipub-ig@w3.org, duga@google.com.

On 11/11/2013 11:20 PM, fantasai wrote: > > Dear Digital Publishing IG, > Please in the future just send a message to the www-style > mailing list and CC yourselves. This will let us respond > directly and thread a cross-posted discussion with you. :) > >> 2. In section 1.3, after the example: >> "Within this specification, the ambiguous term character is used >> as a friendlier synonym for grapheme cluster. See Characters and >> Properties for how to determine the Unicode properties of a >> character." >> "A letter for the purpose of this specification is a character >> belonging to one of the Letter or Number general categories in >> Unicode. [UAX44]" >> If I replace 'character' in the second paragraph with 'grapheme >> cluster', I am not sure I get a reasonable answer. For instance, >> is U+0067 + U+0308 a letter? I don't think U+0308 is, does that >> disqualify the whole cluster? Or is this a different use of the >> term character? Does Unicode define such clusters as belonging >> to all the groups all the code points belong to? > > Ah, that's referring to some text that was recently removed from > Writing Modes. Here's the old version: > http://www.w3.org/TR/2012/WD-css3-writing-modes-20121115/#character-properties > # For the purposes of CSS Writing Modes, the properties of a > # grapheme cluster are given by its base character—except [...] > > I'll have to restore that text, will follow-up on that with a link... Link: http://dev.w3.org/csswg/css-text/#character-properties Note, we also rewrote the section on grapheme clusters as follows: http://dev.w3.org/csswg/css-text/#characters >> 3. The only place the spec mentions that text-transform should >> affect line breaking is in an informative example (#2), at least >> that I saw. Should this be mentioned in a normative section? Some >> line breaking changes are obvious (for instance, changing the >> width of the glyphs will alter line breaking), but others are >> more obscure (for instance, transformation to full width). > > This is implied by the ordering in Appendix A: > http://dev.w3.org/csswg/css-text/#order > > However I can add a note to clarify that point to the text-transform > section. This is done: # Note that, as defined in Text Processing Order of Operations, # text transformation affects line-breaking and other formatting # operations. >> 4. From 5.1, last bullet point: >> "For line breaking in/around ruby, [...] >> However, I would expect the correct breaking would be neither of those, but rather: >> だ[1]大分[3]日数[5]が >> I am not certain how I can interpret the spec to generate those line breaks. > > Good point. This sentence was written before we had a reasonable > draft of the ruby spec to refer to, so I will replace this with > a pointer to that spec, which has a much more involved discussion > of ruby line-breaking: > http://www.w3.org/TR/css-ruby-1/#line-breaks > > I'll drop a link to the updated text once I get in the edits. :) (Fwiw, this is done.) >> 9. In "7.1. Text Alignment", "text-align: start end" sounds a >> lot like "text-align-last: *", giving special treatment to the >> first line instead of the last line, with less control. Perhaps >> there should be a separate property for controlling the first >> line alignment, just like there is for controlling the last line. >> Then text-align could become a shorthand. For example: >> >> text-align: center == text-align-first: center, >> text-align-middle: center, text-align-last: auto >> [...] > > I think I will re-raise this to the WG, will reply with an update. The CSSWG discussed this at the Seoul F2F and decided 1. To make text-align a shorthand, as you suggest. 2. to defer 'text-align-first' to the next level See http://lists.w3.org/Archives/Public/www-style/2014Jun/0167.html Please let us know if you have further comments on this or anything else! ~fantasai
Re: [css-text] comments from DPub IG (Fwd)
Brady Duga   Mon, 21 Jul 2014 20:53:52 +0000

www-style > July 2014 > 0000.html

Received on Monday, 21 July 2014 20:54:20 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net, www-style@w3.org, www-style@w3.org, public-digipub-ig@w3.org.

On Mon Jul 21 2014 at 9:13:29 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > > Link: > http://dev.w3.org/csswg/css-text/#character-properties This text seems better, but Appendix D now ends mid sentence. Or rather, it never quite gets to mid sentence, starting out with "The". > This is done: > > # Note that, as defined in Text Processing Order of Operations, > # text transformation affects line-breaking and other formatting > # operations. > Looks good. I note that the link back to 'text transformation' in Appendix A doesn't actually take you anywhere (in the editors draft). Nor do 'indentation', 'hanging punctuation', or 'text-alignment'. > The CSSWG discussed this at the Seoul F2F and decided > 1. To make text-align a shorthand, as you suggest. > 2. to defer 'text-align-first' to the next level > Cool, sounds reasonable!
Re: [css-text] 'hanging-punctuation' comments
MURAKAMI Shinyu   Thu, 24 Jul 2014 01:29:41 +0900

www-style > July 2014 > 0000.html

Received on Wednesday, 23 July 2014 16:30:16 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: kanghao.lkh@alibaba-inc.com, www-style@w3.org.

fantasai <fantasai.lists@inkedblade.net> wrote on 2014/07/21 22:14:05 > On 11/11/2013 05:23 PM, Kang-Hao (Kenny) Lu wrote: > > (2013/11/12 9:07), Kang-Hao (Kenny) Lu wrote: > >> # Non-zero start and end borders/padding between a hangeable mark and > >> # the edge of the line prevent the mark from hanging. > >> > >> Why doesn't this include 'margin'? > > Good point. I'm not sure why it should exclude margins. I've added margins > to that sentence. > > Murakami-san, could you please verify if this is correct? :) I think excluding margins was correct. Border/padding are visible and hanging marks with them will cause line edges visually uneven, but the margin is different. Shinyu Murakami
Re: [css-text] 'hanging-punctuation' and padding/borders/margins (was 'hanging-punctuation' comments
Koji Ishii   Sat, 26 Jul 2014 15:36:58 +0000

www-style > July 2014 > 0000.html

Received on Saturday, 26 July 2014 15:37:33 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: murakami@antenna.co.jp
Copied to: fantasai.lists@inkedblade.net, kanghao.lkh@alibaba-inc.com, www-style@w3.org.

# Changed the subject to what we’re discussing. On Jul 24, 2014, at 1:29, MURAKAMI Shinyu <murakami@antenna.co.jp> wrote: > fantasai <fantasai.lists@inkedblade.net> wrote on 2014/07/21 22:14:05 >> On 11/11/2013 05:23 PM, Kang-Hao (Kenny) Lu wrote: >>> (2013/11/12 9:07), Kang-Hao (Kenny) Lu wrote: >>>> # Non-zero start and end borders/padding between a hangeable mark and >>>> # the edge of the line prevent the mark from hanging. >>>> >>>> Why doesn't this include 'margin'? >> >> Good point. I'm not sure why it should exclude margins. I've added margins >> to that sentence. >> >> Murakami-san, could you please verify if this is correct? :) > > I think excluding margins was correct. > Border/padding are visible and hanging marks with them will cause > line edges visually uneven, but the margin is different. I agree with Murakami-san. Even more, I started to wonder, maybe this could harm more than it helps. We might have discussed this before, but could you remind me what were the use cases of this definition? One case that pops up in my mind where this definition could harm is: key { border:thin black solid; } <p>Press <key>X</key>.</p> I suppose the period should hang. /koji
Re: [css-text] 'hanging-punctuation' and padding/borders/margins (was 'hanging-punctuation' comments
fantasai   Thu, 31 Jul 2014 22:55:03 +0100

www-style > August 2014 > 0000.html

Received on Friday, 1 August 2014 01:12:57 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 07/26/2014 04:36 PM, Koji Ishii wrote: > # Changed the subject to what we’re discussing. > > On Jul 24, 2014, at 1:29, MURAKAMI Shinyu <murakami@antenna.co.jp> wrote: >> fantasai <fantasai.lists@inkedblade.net> wrote on 2014/07/21 22:14:05 >>> On 11/11/2013 05:23 PM, Kang-Hao (Kenny) Lu wrote: >>>> (2013/11/12 9:07), Kang-Hao (Kenny) Lu wrote: >>>>> # Non-zero start and end borders/padding between a hangeable mark and >>>>> # the edge of the line prevent the mark from hanging. >>>>> >>>>> Why doesn't this include 'margin'? >>> >>> Good point. I'm not sure why it should exclude margins. I've added margins >>> to that sentence. >>> >>> Murakami-san, could you please verify if this is correct? :) >> >> I think excluding margins was correct. >> Border/padding are visible and hanging marks with them will cause >> line edges visually uneven, but the margin is different. > > I agree with Murakami-san. > > Even more, I started to wonder, maybe this could harm more than it helps. > We might have discussed this before, but could you remind me what were > the use cases of this definition? > > One case that pops up in my mind where this definition could harm is: > key { border:thin black solid; } > <p>Press <key>X</key>.</p> > I suppose the period should hang. The period does hang. Why would it not? In this example, the period would not hang, because there is a border between it and the edge: <p>Press <key>B.S.</key></p> ~fantasai
Re: [css-text] 'hanging-punctuation' and padding/borders/margins (was 'hanging-punctuation' comments
Koji Ishii   Sat, 2 Aug 2014 08:37:03 +0000

www-style > August 2014 > 0000.html

Received on Saturday, 2 August 2014 08:37:43 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: www-style@w3.org, www-style@w3.org.

>> One case that pops up in my mind where this definition could harm is: >> key { border:thin black solid; } >> <p>Press <key>X</key>.</p> >> I suppose the period should hang. > > The period does hang. Why would it not? Ah, ok, I thought when hanged, the edge of the line is before the hanged character. You probably mean “the edge of the line” is where the line wraps. /koji
[css-line-grid] (mostly) editorial comments on the ED
Dave Cramer   Fri, 15 Aug 2014 15:32:06 -0400

www-style > August 2014 > 0000.html

Received on Friday, 15 August 2014 19:32:33 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: stearns@adobe.com, www-style@w3.org, www-style@w3.org.

Hi Alan, Here are a few observations after reading through the ED. [1] Perhaps due to my background in print, I'm used to seeing baseline grids, and find them to be the easiest way to visualize text alignment. A baseline grid might make figures 1 and 2 a little easier to understand at a glance, but others might disagree. [2] What's the intended alignment for the sidebar in figure 3? In my browsers, neither the top of the text nor the baseline align with the first line of the main text. I think of it as a lovely example of the need for this functionality :) [3] I didn't immediately find definitions of text-over baseline and text-under baselines. CSS Line Layout uses text-over-edge and text-under-edge, but also has text-before-edge and text-after-edge. The original definitions seem to be in CSS Writing Modes. [4] Section 3.1. I'd like to see an example of line-snap: contains. [5] Example 2 is very good, and is a nice introduction to how line-snapping works. [6] For Example 3, I would have found it helpful to have a figure showing the original situation, before any shifting or snapping. Perhaps having a more visible border around the images would help illustrate the vertical centering (there's not much contrast between the white figure background and the example background color). [7] Example 4 might benefit from showing the intermediate stage as well as the start and end point. [8] Use case: a very common situation for us is a page of regular text, interrupted by a blockquote that uses a different font size and line height: p { font-size: 12pt; line-height: 16pt; } blockquote p { font-size: 10pt; line-height: 13pt; } There are two constraints: [A] The regular text after the blockquote should align to the baseline grid [B] The space above and below the blockquote should be equal. Using a line grid for the regular text would satisfy the first constraint, but not the second. Would applying box-snap: center to the blockquote do this? [9] I probably shouldn't mention a desire to align the last text baseline of a page float (like a sidebar) to a line grid :) Regards, Dave
Re: [css-line-grid] (mostly) editorial comments on the ED
Alan Stearns   Fri, 15 Aug 2014 20:05:53 +0000

www-style > August 2014 > 0000.html

Received on Friday, 15 August 2014 20:06:37 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: dauwhe@gmail.com, www-style@w3.org, www-style@w3.org.

On 8/15/14, 12:32 PM, "Dave Cramer" <dauwhe@gmail.com> wrote: >Hi Alan, > > >Here are a few observations after reading through the ED. Thanks for the read-through! > >[1] Perhaps due to my background in print, I'm used to seeing baseline >grids, and find them to be the easiest way to visualize text alignment. A >baseline grid might make figures 1 and 2 a little easier to understand at >a glance, but others might disagree. I agree. Given the content in figure 1, I think it should show an alphabetic baseline grid. >[2] What's the intended alignment for the sidebar in figure 3? In my >browsers, neither the top of the text nor the baseline align with the >first line of the main text. I think of it as a lovely example of the >need for this functionality :) Correct - it appears to be showing identical line-heights, but all of the alphabetic baselines should be aligned. There’s a separate solution that would not have identical line-heights and just have the first line of the side note baseline align with the main text’s baseline. That could be an example for box-snap:first-baseline. >[3] I didn't immediately find definitions of text-over baseline and >text-under baselines. CSS Line Layout uses text-over-edge and >text-under-edge, but also has text-before-edge and text-after-edge. The >original definitions seem to be in CSS Writing Modes. Thanks - I noticed the lack of definitions when I did the bikeshed conversion, but hadn’t yet fixed them up. >[4] Section 3.1. I'd like to see an example of line-snap: contains. There should be two examples - one where a line small enough is contained by consecutive text-over and text-under baselines, and one where a larger line is contained by non-consecutive baselines. >[5] Example 2 is very good, and is a nice introduction to how >line-snapping works. > > >[6] For Example 3, I would have found it helpful to have a figure showing >the original situation, before any shifting or snapping. Perhaps having a >more visible border around the images would help illustrate the vertical >centering (there's not much contrast > between the white figure background and the example background color). Hmm, I see what you mean. It doesn’t help that the line-grid isn’t centered in the picture, either. I omitted the earlier steps, because in my mind they’re identical to figures 7 and 8 above. I could make that more explicit in the text. >[7] Example 4 might benefit from showing the intermediate stage as well >as the start and end point. The only issue with that is that the intermediate stage either has the block top-aligned (as in figure 8) or the partial shifting doesn’t directly show how it’s being influenced by the grid. I do see that I need to change ‘centering’ to ‘end-alignment’ in the prose. >[8] Use case: a very common situation for us is a page of regular text, >interrupted by a blockquote that uses a different font size and line >height: > > >p { font-size: 12pt; line-height: 16pt; } > >blockquote p { font-size: 10pt; line-height: 13pt; } > > >There are two constraints: > > >[A] The regular text after the blockquote should align to the baseline >grid > >[B] The space above and below the blockquote should be equal. > > >Using a line grid for the regular text would satisfy the first >constraint, but not the second. Would applying box-snap: center to the >blockquote do this? It would get fairly close to your second constraint. The perceptual space might be slightly different depending on the regular text’s descent and cap height. A large cap height and small descent would make the block quote look slightly lower than center. >[9] I probably shouldn't mention a desire to align the last text baseline >of a page float (like a sidebar) to a line grid :) That should work with box-snap:last-baseline. Are you concerned with how line grids will interact with float positioning, or do you have some other complication in mind? Thanks, Alan
Re: [css-line-grid] (mostly) editorial comments on the ED
Dave Cramer   Fri, 15 Aug 2014 16:32:05 -0400

www-style > August 2014 > 0000.html

Received on Friday, 15 August 2014 20:32:33 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: stearns@adobe.com
Copied to: www-style@w3.org, www-style@w3.org.

On Fri, Aug 15, 2014 at 4:05 PM, Alan Stearns <stearns@adobe.com> wrote: > On 8/15/14, 12:32 PM, "Dave Cramer" <dauwhe@gmail.com> wrote: > > >[9] I probably shouldn't mention a desire to align the last text baseline > >of a page float (like a sidebar) to a line grid :) > > That should work with box-snap:last-baseline. Are you concerned with how > line grids will interact with float positioning, or do you have some other > complication in mind? > That was the complication I had in mind. I'm afraid to say "float" in this crowd :) Thanks, Dave
Re: [css-flexbox] PF comment on Flexbox: Advise authors about reordering
fantasai   Mon, 18 Aug 2014 14:32:44 -0700

www-style > August 2014 > 0000.html

Received on Monday, 18 August 2014 21:33:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: cooper@w3.org, www-style@w3.org
Copied to: wai-liaison@w3.org.

On 05/21/2014 09:48 AM, Michael Cooper wrote: > Below is a review from the Protocols and Formats Working Group on CSS 3 Flexbox > <http://www.w3.org/TR/2014/WD-css-flexbox-1-20140325/>. > > <blockquote> > 5.4.1 Reordering and Accessibility > > The order property does not affect ordering in non-visual media (such as speech). Likewise, order does not affect the default > traversal order of sequential navigation modes (such as cycling through links, see e.g. nav-index [CSS3UI] or tabindex > [HTML40]). Authors must use order only for visual, not logical, reordering of content; style sheets that use order to perform > logical reordering are non-conforming. > > This is so that non-visual media and non-CSS UAs, which typically present content linearly, can rely on a logical source > order, while order is used to tailor the visual order. (Since visual perception is two-dimensional and non-linear, the desired > visual order is not always logical.) > </blockquote> > > The reordering and accessibility section mentions tabindex and nav-index. However, it's not quite strong enough on the > importance of focus order for visual keyboard users. > > We suggest to add "authors who change the order using order, flex-direction=row-reverse, flex-direction=column-reverse, or > flex-flow (and ??) must|should adjust the focus order with either nav-index or tabindex." The reason why tabindex and nav-index are not affected by Flexbox reordering is *because* we want the focus order to follow the source order. If the logical order (that speech and focus should follow) needs to be reordered, that should be done at the source level, and not with flex-flow. I think the spec is reasonably clear about this in the section you just quoted. Therefore I am rejecting your suggestion. It is actively harmful. Authors who want such reordering should reorder the source order instead of using flex-flow. ~fantasai
[selectors] L4 comments
Daniel Glazman   Thu, 13 Nov 2014 14:07:04 +0100

www-style > November 2014 > 0000.html

Received on Thursday, 13 November 2014 13:07:29 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Section 12.4.3 :first-child is an element that precedes all of its siblings (if any) but browsers do not implement that, they implement an element that precedes all of its sibling elements (if any) Same issue for :last-child and :only-child Section 12.2 Is an element containing only shadow elements empty? </Daniel>
Re: [selectors] L4 comments
Boris Zbarsky   Thu, 13 Nov 2014 10:54:16 -0500

www-style > November 2014 > 0000.html

Received on Thursday, 13 November 2014 15:54:46 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 11/13/14, 8:07 AM, Daniel Glazman wrote: > Section 12.4.3 > > :first-child is > > an element that precedes all of its siblings (if any) Isn't this due to the fact that CSS operates on an abstract "element tree" which doesn't actually match the DOM tree, and in particular only contains the element nodes? That said, I obviously welcome any movement away from that confusing abstraction. ;) -Boris
Re: [css-align] 2 issues / comments on the specification
fantasai   Tue, 16 Dec 2014 19:31:26 -0800

www-style > December 2014 > 0000.html

Received on Wednesday, 17 December 2014 03:32:30 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 01/29/2014 05:41 PM, Julien Chaffraix wrote: > Hi, > > * 'flex-end' resolves to 'start' on non-flex items > > This is very confusing and I think it would make more sense to have it > resolve to 'end' to be consistent with the author's cue. Okay, we've changed this as you suggest. > * Currently the specification is silent on what happens when > 'self-start' and 'self-end' are set on an orthogonal writing mode. > > I have thought of 2 ways to think about this (there is probably others): > A) As the axes from the containing block / child are orthogonal, it is > invalid and we would default to 'start' / 'end' (based on the original > property). > B) We use the child's coordinate system to resolve start / end into a > physical direction and use it for the resolution. > >>From my perspective, A) makes more sense as B) would involve looking > at the opposite axis (e.g. 'justify-self' would end up working on the > child's block-axis). This makes no sense. There's no reason why you cannot compute the sides of 'self-start' and 'self-end' on an orthogonal flow. The relevant axis is determined by the property, and start vs. end is determined by the box's specified block or inline flow direction, whichever is in that axis. ~fantasai
Re: [css-align] 2 issues / comments on the specification
fantasai   Tue, 16 Dec 2014 19:32:32 -0800

www-style > December 2014 > 0000.html

Received on Wednesday, 17 December 2014 03:33:12 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, dholbert@mozilla.com.

On 02/03/2014 03:34 PM, Tab Atkins Jr. wrote: > > Somewhat unrelated, I note that 'flex-start/end' are defined to be > "equivalent to" start in a non-flex context. We should probably just > compute them to start instead; doing so relies on information that is > generally okay to deal with in computed values (just the 'display' of > the element's parent). I'm not sure about this. I agree it seems very straightforward, but didn't we run into a problem with looking at 'display' of the element's parent during the flexbox cycle? Pinging Mozilla folks, since it was their issue. ~fantasai
[CSSWG] CSS Fragmentation Level 3 Last Call for Comments
fantasai   Sat, 28 Feb 2015 13:18:44 -0500

www-style > February 2015 > 0000.html

Received on Saturday, 28 February 2015 18:19:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-digipub-ig@w3.org, epub-working-group@googlegroups.com, murakami@antenna.co.jp.

The CSS WG has published an updated Working Draft of the CSS Fragmentation Module Level 3: http://www.w3.org/TR/css3-break/ This module describes the fragmentation model that partitions a flow into pages, columns, or regions and provides controls for breaking. We expect this to be the last WD before CR, and plan to transition at the end of March. Please review and send us any comments. If you plan to review but aren't sure you have time, send us a note so that we know to wait for your comments. We are particularly looking for feedback on * Which rules are dropped when breaks are overconstrained http://www.w3.org/TR/2015/WD-css3-break-20150129/#unforced-breaks * Anything that appears to be insufficiently specified or explained. We are particularly looking for reviews from * Anyone who makes a print or PDF output implementation. * Anyone who makes an eBook implementation. * Anyone who authors documents for such implementations. We will also welcome any submissions of better/more examples and diagrams. Significant changes since the last WD are listed at: http://www.w3.org/TR/2015/WD-css3-break-20150129/#changes Please send any comments to this mailing list, <www-style@w3.org>, and please, prefix the subject line with [css-break] (as I did on this message). For the CSS WG, ~fantasai
Re: [CSSWG] CSS Fragmentation Level 3 Last Call for Comments
François REMY   Sat, 7 Mar 2015 17:28:16 +0000

www-style > March 2015 > 0000.html

Received on Saturday, 7 March 2015 18:06:53 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net, murakami@antenna.co.jp
Copied to: www-style@w3.org.

Hi, I’ve started reviewing the spec, and fwiw I think Issue 1 is handled properly at this time. I’ve also started some work to add diagrams to the spec. Here’s one I think we could use to visually represent the definitions: We could annotate the fragmentainers, the fragmentation context, the content flow, the fragmentation (arrow) as well as the remaining extend after the last element. What do you think? I was also thinking about adding diagrams to explain more phenomenons like parallel fragmentation: Ditto for the filling of the remaining fragementainer extent on break: Do you have any particular concern or comment before I proceed to expand the diagrams coverage proposal? Best regards, François ________________________________ PS: Please, feel free to help the spec by submitting better diagrams than mine if you feel like, I’m certainly not an expert at making diagrams, but I have enough interest in this spec to make sure at least someone does that work ;-) De : Fantasai Envoyé : ‎samedi‎ ‎28‎ ‎février‎ ‎2015 ‎19‎:‎22 À : CSS WG, public-digipub-ig@w3.org, epub-working-group@googlegroups.com, MURAKAMI Shinyu The CSS WG has published an updated Working Draft of the CSS Fragmentation Module Level 3: http://www.w3.org/TR/css3-break/ This module describes the fragmentation model that partitions a flow into pages, columns, or regions and provides controls for breaking. We expect this to be the last WD before CR, and plan to transition at the end of March. Please review and send us any comments. If you plan to review but aren't sure you have time, send us a note so that we know to wait for your comments. We are particularly looking for feedback on * Which rules are dropped when breaks are overconstrained http://www.w3.org/TR/2015/WD-css3-break-20150129/#unforced-breaks * Anything that appears to be insufficiently specified or explained. We are particularly looking for reviews from * Anyone who makes a print or PDF output implementation. * Anyone who makes an eBook implementation. * Anyone who authors documents for such implementations. We will also welcome any submissions of better/more examples and diagrams. Significant changes since the last WD are listed at: http://www.w3.org/TR/2015/WD-css3-break-20150129/#changes Please send any comments to this mailing list, <www-style@w3.org>, and please, prefix the subject line with [css-break] (as I did on this message). For the CSS WG, ~fantasai
[css-grid] Comments about grid item 'display' value and the term "grid-level boxes"
Mats Palmgren   Thu, 26 Mar 2015 16:11:05 +0000

www-style > March 2015 > 0000.html

Received on Thursday, 26 March 2015 16:11:59 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

Hi, I have two comments on the following text from "4. Grid Items": "A grid item establishes a new formatting context for its contents. The type of this formatting context is determined by its display value, as usual. The computed display of a grid item is determined by applying the table in CSS 2.1 Chapter 9.7. However, grid items are grid-level boxes, not block-level boxes: they participate in their container's grid formatting context, not in a block formatting context." http://dev.w3.org/csswg/css-grid/#grid-items 1. It omits that a grid item's 'display' value is blockified. Please add the equivalent of this text from Flexbox: http://dev.w3.org/csswg/css-flexbox-1/#flex-items "The display value of a flex item is blockified: if the specified display of an in-flow child of an element generating a flex container is an inline-level value, it computes to its block-level equivalent. (See CSS2.1§9.7 [CSS21] and CSS Display [CSS3-DISPLAY] for details on this type of display value conversion.)" 2. I searched the spec text for "grid-level box" to try to find its definition but this is the only occurrence. This is when I realized that the last sentence above *is* the definition of "grid-level box", i.e. a box that participate in their container's grid formatting context. I found this a bit confusing and would like you to consider reformulating that last sentence to make it clear that it's defining the term "grid-level box" there, rather than just mentioning a detail about them in passing. Thanks, Mats
[css-ui] Final review: small comments
Florian Rivoal   Fri, 10 Apr 2015 17:32:15 +0200

www-style > April 2015 > 0000.html

Received on Friday, 10 April 2015 15:32:39 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org
Copied to: tantek@cs.stanford.edu.

Hi Tantek, As we now have a resolution on all open issues, I though this would be a good time to go through the spec again to make sure everything is tight and ready for CR. Here are a few minor things I've found: 1) The abstract still mentions selectors, even though there are not longer any selectors in the spec 2) The list of features at risk includes "outline-offset property negative values", but this would be better listed as "constraints on outline-offset property negative values" to match what the text actually says 3) Modules interactions lists what this spec supersedes. It should now include one extra item: - Information on the stacking of outlines defined in CSS 2.1 Appendix E http://www.w3.org/TR/CSS21/zindex.html 4) We should now be able to remove "Issue 1: 69 box-sizing insufficiently specified for replaced elements." 5) http://dev.w3.org/csswg/css-ui/#ellipsing-details states: "Ellipsing occurs after relative positioning and other graphical transformations" Given that ellipsis applies to inline text, and that transforms do not apply to inlines, what do "other graphical transformations" refer to? Let's either clarify or remove. 6) There a missing closing </p> tag after PARAGRAPH in example 6, causing the sample rendering to be different from what the example claims it will be. 7) The section on directional navigation has a note about welcoming feedback about the behavior for otherwise non focusable elements. Is the a WG or some other body that we could contact to request feedback from? A note in a spec is not a very proactive request for feedback. I also have 5 more substantive comments which I will send in separate mails. Once we're done with that, and pending the edits for cursor formats, I think we will be pretty much ready for CR. - Florian
Re: [css-ui] Final review: small comments
Tantek Çelik   Tue, 21 Apr 2015 23:05:01 -0700

www-style > April 2015 > 0000.html

Received on Wednesday, 22 April 2015 06:06:16 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: florian@rivoal.net
Copied to: www-style@w3.org, tantek@cs.stanford.edu.

On Fri, Apr 10, 2015 at 8:32 AM, Florian Rivoal <florian@rivoal.net> wrote: > Hi Tantek, > > As we now have a resolution on all open issues, I though this would be > a good time to go through the spec again to make sure everything is > tight and ready for CR. > > Here are a few minor things I've found: > > 1) The abstract still mentions selectors, even though there are not > longer any selectors in the spec Indeed. Removed. > 2) The list of features at risk includes > "outline-offset property negative values", but this would be better > listed as "constraints on outline-offset property negative values" > to match what the text actually says I don't think that matters but I also don't object to the extra text. Added. > 3) Modules interactions lists what this spec supersedes. It should > now include one extra item: > > - Information on the stacking of outlines defined > in CSS 2.1 Appendix E http://www.w3.org/TR/CSS21/zindex.html Added to the list of sections that are superseded from CSS2.1 > 4) We should now be able to remove > "Issue 1: 69 box-sizing insufficiently specified for replaced elements." Indeed. > 5) http://dev.w3.org/csswg/css-ui/#ellipsing-details states: > "Ellipsing occurs after relative positioning and other graphical transformations" > Given that ellipsis applies to inline text, and that transforms do not apply to > inlines, what do "other graphical transformations" refer to? Let's either clarify > or remove. >From my recollection we deliberately agreed on this language when we last discussed this at a f2f. I'd prefer to leave as-is, and if there is a specific proposal for clarifying (e.g. based on implementer or ideal behavior), it can be done in level 4. > 6) There a missing closing </p> tag after PARAGRAPH in example 6, > causing the sample rendering to be different from what the example > claims it will be. Note sure how that got dropped. Good catch. > 7) The section on directional navigation has a note about welcoming > feedback about the behavior for otherwise non focusable elements. > Is the a WG or some other body that we could contact to request > feedback from? A note in a spec is not a very proactive request > for feedback. That note roughly reflects what we agreed to after our discussions at the Sydney f2f. We're not looking for feedback from a specific WG, but rather as the note says, from implementers, and authors using those properties. No change needed. > I also have 5 more substantive comments which I will send in separate mails. Once we're done with that, and pending the edits for cursor formats, I think we will be pretty much ready for CR. I'm ok with continuing to publish WDs until we're not finding issues. Even if that means we publish the same thing twice just for a status change, or perhaps we take the opportunity to add some more non-normative (but illustrative) examples. Thanks, Tantek
Re: [css-ui] Final review: small comments
Florian Rivoal   Wed, 22 Apr 2015 11:11:51 +0200

www-style > April 2015 > 0000.html

Received on Wednesday, 22 April 2015 09:12:15 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: tantek@cs.stanford.edu
Copied to: www-style@w3.org.

> > On 22 Apr 2015, at 08:05, Tantek Çelik <tantek@cs.stanford.edu> wrote: > >> 5) http://dev.w3.org/csswg/css-ui/#ellipsing-details states: >> "Ellipsing occurs after relative positioning and other graphical transformations" >> Given that ellipsis applies to inline text, and that transforms do not apply to >> inlines, what do "other graphical transformations" refer to? Let's either clarify >> or remove. > >> From my recollection we deliberately agreed on this language when we > last discussed this at a f2f. I'd prefer to leave as-is, and if there > is a specific proposal for clarifying (e.g. based on implementer or > ideal behavior), it can be done in level 4. If we agreed on this wording, fine by me. Just for my information, what do "other graphical transformations" refer to? >> I also have 5 more substantive comments which I will send in separate mails. Once we're done with that, and pending the edits for cursor formats, I think we will be pretty much ready for CR. > > I'm ok with continuing to publish WDs until we're not finding issues. > Even if that means we publish the same thing twice just for a status > change, or perhaps we take the opportunity to add some more > non-normative (but illustrative) examples. Sure, sounds good to me. - Florian
Re: [css-grid] Comments about grid item 'display' value and the term "grid-level boxes"
"Tab Atkins Jr."   Thu, 7 May 2015 16:24:42 -0700

www-style > May 2015 > 0000.html

Received on Thursday, 7 May 2015 23:25:30 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: mats@mozilla.com
Copied to: www-style@w3.org, www-style@w3.org.

On Thu, Mar 26, 2015 at 9:11 AM, Mats Palmgren <mats@mozilla.com> wrote: > I have two comments on the following text from "4. Grid Items": > "A grid item establishes a new formatting context for its contents. > The type of this formatting context is determined by its display > value, as usual. The computed display of a grid item is determined > by applying the table in CSS 2.1 Chapter 9.7. However, grid items > are grid-level boxes, not block-level boxes: they participate in > their container's grid formatting context, not in a block > formatting context." > http://dev.w3.org/csswg/css-grid/#grid-items > > 1. It omits that a grid item's 'display' value is blockified. > Please add the equivalent of this text from Flexbox: > > http://dev.w3.org/csswg/css-flexbox-1/#flex-items > "The display value of a flex item is blockified: if the specified > display of an in-flow child of an element generating a flex > container is an inline-level value, it computes to its block-level > equivalent. (See CSS2.1§9.7 [CSS21] and CSS Display [CSS3-DISPLAY] > for details on this type of display value conversion.)" Done, thanks. > 2. I searched the spec text for "grid-level box" to try to find > its definition but this is the only occurrence. This is when > I realized that the last sentence above *is* the definition of > "grid-level box", i.e. a box that participate in their > container's grid formatting context. I found this a bit > confusing and would like you to consider reformulating that > last sentence to make it clear that it's defining the term > "grid-level box" there, rather than just mentioning a detail > about them in passing. We've added an actual <dfn> to that term, to make it clear we're defining the term. (And did the same for "flex-level" in Flexbox.) ~TJ and fantasai
[css-round-display] comments on CSS round
Jonathan Kingston   Thu, 04 Jun 2015 00:10:34 +0000

www-style > June 2015 > 0000.html

Received on Thursday, 4 June 2015 00:11:14 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

With new devices popping up all over now with different screens of shapes and sizes would it make more sense for these changes to have further clarity around different display shapes? For example there are half moon shaped watches, oblong screens and also VR headsets which use different shapes. Issues for different screen shapes - No media queries for the different device profiles - Display is defined as circle(50% at 50%, 50%) in a regular round display further clarity would be needed around display shape. - Polar position doesn't always apply here - Some form of CSSOM shape interface for JavaScript would likely be needed. Issues - Code example issue in Example 4 #container { #shape-inside: display; // the same as circle(50% at 50%, 50%) in a regular round display } This should likely just be shape-inside: display; without the #. - The Example 6 code is likely the wrong way around: <div id="circle1" style="polar-angle: 0deg; polar-distance: 20%"></div> <div id="circle2" style="polar-angle: 90deg; polar-distance: 50%"></div> Polar distance should be swapped to be: <div id="circle1" style="polar-angle: 0deg; polar-distance: 50%"></div> < div id="circle2" style="polar-angle: 90deg; polar-distance: 20%"></div> To match the image provided. I also thing due to the form factor of the device hit-testing becomes a far more important issue: http://discourse.specifiction.org/t/interactive-area-and-shape-outside/499 This was copied from the original thread at the request of Florian: http://discourse.specifiction.org/t/css-round-display/790/3 Kind regards Jonathan
Re: [css-round-display] comments on CSS round
"Hyojin Song"   Thu, 4 Jun 2015 16:07:40 +0900

www-style > June 2015 > 0000.html

Received on Thursday, 4 June 2015 07:08:12 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jonathan@jooped.com
Copied to: www-style@w3.org.

Hi Jonathan, Thank you for your interests and support for the CSS Round Display. Please find the inline comments. I've also replied the comments to your thread in the specification.org site. Thanks Hyojin Song On Thu, June 4, 2015 at 12:10 AM, Jonathan Kingston <jonathan@jooped.com> Wrote: > With new devices popping up all over now with different screens of shapes > and sizes would it make more sense for these changes to have further > clarity around different display shapes? > > For example there are half moon shaped watches, oblong screens and also VR > headsets which use different shapes. > > Issues for different screen shapes > > - No media queries for the different device profiles > - Display is defined as circle(50% at 50%, 50%) in a regular round > display further clarity would be needed around display shape. > - Polar position doesn't always apply here > - Some form of CSSOM shape interface for JavaScript would likely be > needed. What you mention is very reasonable thing, and I will also consider the issues. > Issues > > - Code example issue in Example 4 > > #container { #shape-inside: display; // the same as circle(50% at 50%, 50%) > in a regular round display } > > This should likely just be shape-inside: display; without the #. The issue you indicated is exactly right, and I've already modified the issue about a month ago. I think you have an eye like a hawk :) Even though I reviewed the spec with deliberation, I didn't catch the error. > > > - The Example 6 code is likely the wrong way around: > > <div id="circle1" style="polar-angle: 0deg; polar-distance: 20%"></div> <div > id="circle2" style="polar-angle: 90deg; polar-distance: 50%"></div> > > Polar distance should be swapped to be: > > <div id="circle1" style="polar-angle: 0deg; polar-distance: 50%"></div> < > div id="circle2" style="polar-angle: 90deg; polar-distance: 20%"></div> > > To match the image provided. I think it depends on where is the major axis, and it is normally the right direction as the 0 degree. You can find the background materials in the wiki page as follows. http://en.wikipedia.org/wiki/Polar_coordinate_system If I miss something, let me know through this mailing list. > I also thing due to the form factor of the device hit-testing becomes a far > more important issue: > http://discourse.specifiction.org/t/interactive-area-and-shape-outside/499 I will review the issue soon. > This was copied from the original thread at the request of Florian: > http://discourse.specifiction.org/t/css-round-display/790/3 Thanks Florian :) > Kind regards > Jonathan
Re: [css-round-display] comments on CSS round
Florian Rivoal   Thu, 4 Jun 2015 12:02:47 +0200

www-style > June 2015 > 0000.html

Received on Thursday, 4 June 2015 10:03:09 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: hyojin22.song@lge.com
Copied to: jonathan@jooped.com, www-style@w3.org.

On 04 Jun 2015, at 09:07, Hyojin Song <hyojin22.song@lge.com> wrote: > On Thu, June 4, 2015 at 12:10 AM, Jonathan Kingston <jonathan@jooped.com> > Wrote: >> >> - The Example 6 code is likely the wrong way around: >> >> <div id="circle1" style="polar-angle: 0deg; polar-distance: 20%"></div> <div >> id="circle2" style="polar-angle: 90deg; polar-distance: 50%"></div> >> >> Polar distance should be swapped to be: >> >> <div id="circle1" style="polar-angle: 0deg; polar-distance: 50%"></div> < >> div id="circle2" style="polar-angle: 90deg; polar-distance: 20%"></div> >> >> To match the image provided. > > I think it depends on where is the major axis, and it is normally the right direction as the 0 degree. > You can find the background materials in the wiki page as follows. > http://en.wikipedia.org/wiki/Polar_coordinate_system > If I miss something, let me know through this mailing list. The convention in math is as you say, but other uses of <angle> in css have positive values go clockwise, and with 0 at the top. There aren't that many uses yet, but I think it would be good to be consistent. Either way, the specification needs to be explicit about how angles should be interpreted. >> This was copied from the original thread at the request of Florian: >> http://discourse.specifiction.org/t/css-round-display/790/3 > > Thanks Florian :) My pleasure :) - Florian
Re: [css-round-display] comments on CSS round
"Tab Atkins Jr."   Thu, 4 Jun 2015 12:01:00 -0700

www-style > June 2015 > 0000.html

Received on Thursday, 4 June 2015 19:01:48 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: florian@rivoal.net
Copied to: hyojin22.song@lge.com, jonathan@jooped.com, www-style@w3.org.

On Thu, Jun 4, 2015 at 3:02 AM, Florian Rivoal <florian@rivoal.net> wrote: > The convention in math is as you say, but other uses of <angle> in css > have positive values go clockwise, and with 0 at the top. There aren't > that many uses yet, but I think it would be good to be consistent. I'll make a stronger statement - we MUST be consistent, and the pattern that CSS and SVG have already established is bearing angles (0deg = up, positive angles = clockwise). ~TJ
RE: [css-round-display] comments on CSS round
"Hyojin Song"   Fri, 5 Jun 2015 09:29:03 +0900

www-style > June 2015 > 0000.html

Received on Friday, 5 June 2015 00:29:43 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: florian@rivoal.net, jonathan@jooped.com, www-style@w3.org.

I definitely understand the explanation Tab mentioned, and I applied the contents in CSS Round Display spec a moment ago. I couldn't find any information about bearing angles (0deg = up). Even though the information is internalized in several CSS and SVG spec, I think it would be specified in CSS Values and Units Module spec or any other similar spec. Thanks for the important information, TJ, Florian, and Jonathan. ~hyojin -----Original Message----- From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] Sent: Friday, June 05, 2015 4:01 AM To: Florian Rivoal Cc: Hyojin Song; Jonathan Kingston; www-style list Subject: Re: [css-round-display] comments on CSS round On Thu, Jun 4, 2015 at 3:02 AM, Florian Rivoal <florian@rivoal.net> wrote: > The convention in math is as you say, but other uses of <angle> in css > have positive values go clockwise, and with 0 at the top. There aren't > that many uses yet, but I think it would be good to be consistent. I'll make a stronger statement - we MUST be consistent, and the pattern that CSS and SVG have already established is bearing angles (0deg = up, positive angles = clockwise). ~TJ
Re: [css-round-display] comments on CSS round
"Tab Atkins Jr."   Thu, 4 Jun 2015 18:12:29 -0700

www-style > June 2015 > 0000.html

Received on Friday, 5 June 2015 01:13:18 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: hyojin22.song@lge.com
Copied to: florian@rivoal.net, jonathan@jooped.com, www-style@w3.org.

On Thu, Jun 4, 2015 at 5:29 PM, Hyojin Song <hyojin22.song@lge.com> wrote: > I definitely understand the explanation Tab mentioned, and I applied the contents in CSS Round Display spec a moment ago. > > I couldn't find any information about bearing angles (0deg = up). Even though the information is internalized in several CSS and SVG spec, I think it would be specified in CSS Values and Units Module spec or any other similar spec. Good point. I've edited Values & Units to make this clear. Sorry for not having that explicit earlier. ~TJ
[CSS21] enhancement: comment format for surviving file being minified
Nick Levinson   Sun, 21 Jun 2015 05:12:19 +0000

www-style > July 2015 > 0000.html

Received on Friday, 10 July 2015 08:48:17 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Hopefully, this is not a duplicate email (I thought I sent one a few minutes ago but apparently not). Minifying removes comments some of which should, however, stay in place for the benefit of website visitors. We need a comment format that minifiers will recognize for preserving selected comments. For example, I use comments for information that is not important enough to display on a Web page but should be available to someone willing to look in the source code, such as legal information. An example of that is humanly readable copyright information that applies only to the source code and not to the displayed object code itself. This should apply to all CSS that is used in level 3.
Re: [CSS21] enhancement: comment format for surviving file being minified
Michiel Bijl   Fri, 10 Jul 2015 11:07:37 +0200

www-style > July 2015 > 0000.html

Received on Friday, 10 July 2015 09:08:18 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: nick_levinson@yahoo.com
Copied to: www-style@w3.org, www-style@w3.org.

Most minifyers preserve the following syntax: /* This gets removed */ /*! This is preserved */ —Michiel > On 21 Jun 2015, at 07:12, Nick Levinson <nick_levinson@yahoo.com> wrote: > > Hopefully, this is not a duplicate email (I thought I sent one a few minutes ago but apparently not). > > Minifying removes comments some of which should, however, stay in place for the benefit of website visitors. We need a comment format that minifiers will recognize for preserving selected comments. For example, I use comments for information that is not important enough to display on a Web page but should be available to someone willing to look in the source code, such as legal information. An example of that is humanly readable copyright information that applies only to the source code and not to the displayed object code itself. This should apply to all CSS that is used in level 3. > > > >
Re: [CSS21] enhancement: comment format for surviving file being minified
"Tab Atkins Jr."   Fri, 10 Jul 2015 17:02:56 -0700

www-style > July 2015 > 0000.html

Received on Saturday, 11 July 2015 00:03:45 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: nick_levinson@yahoo.com
Copied to: www-style@w3.org.

On Sat, Jun 20, 2015 at 10:12 PM, Nick Levinson <nick_levinson@yahoo.com> wrote: > Hopefully, this is not a duplicate email (I thought I sent one a few minutes ago but apparently not). > > Minifying removes comments some of which should, however, stay in place for the benefit of website visitors. We need a comment format that minifiers will recognize for preserving selected comments. For example, I use comments for information that is not important enough to display on a Web page but should be available to someone willing to look in the source code, such as legal information. An example of that is humanly readable copyright information that applies only to the source code and not to the displayed object code itself. This should apply to all CSS that is used in level 3. Minified code isn't meant to be read in the first place. The best practice here is to keep the readable version on the site too (just not linked to) and use a Source Map (generated by your pipeline) to translate between the two. Here's an example of using source maps in Sass <http://thesassway.com/intermediate/using-source-maps-with-sass> and here's a description of the source format <http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/> (it's written for JS, but it applies to CSS just as well). Or, according to Michiel, you can apparently use the de-facto standard of putting a bang right after the comment opening token. ~TJ
Re: [CSS21] enhancement: comment format for surviving file being minified
Nick Levinson   Sat, 11 Jul 2015 00:54:19 +0000

www-style > July 2015 > 0000.html

Received on Thursday, 23 July 2015 09:15:16 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

I like the bang (exclamation point) spacelessly following the opening delimiter. The other method, source mapping, is too complicated for some comments, such as legal notices, which are for people who may not be programmers and may have a hard enough time realizing they should go to the source code without having to have a developer version of a browser, too. Given that there already are at least two implementations of the bang method ("[m]ost" per Michiel Bijl's message), can a CSS spec be updated to include it so that other tools will agree on it?
Re: [CSS21] enhancement: comment format for surviving file being minified
Nick Levinson   Tue, 18 Aug 2015 04:02:32 +0000

www-style > August 2015 > 0187.html

Received on Thursday, 20 August 2015 11:29:20 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

I found implementations favoring the same effect as more or less proposed in this thread, the bang immediately after the opening tag: YUI preserves comments beginning with "/*!" (without quotation marks). <https://github.com/yui/yuicompressor/blob/master/README.md>, as accessed Aug. 15, 2015. rCSSmin 1.0.5: "Comments starting with an exclamation mark (!) can be kept optionally." <http://opensource.perlig.de/rcssmin/>, as accessed Aug. 15, 2015. W3 Total Cache (W3TC): Comments including certain strings (at least "google_ad_" or "RSPEAK_" (without quotation marks)) will be preserved. <http://code.tutsplus.com/articles/configuring-w3-total-cache-advanced-minification-settings--wp-31043>, as accessed Aug. 15, 2015. CSS::Minifier (CSS-Minifier-0.01), ver. 0.01 (thus, by convention, beta) can create or preserve only a copyright comment. <http://search.cpan.org/~pmichaux/CSS-Minifier-0.01/lib/CSS/Minifier.pm>, as accessed Aug. 16, 2015. -- Nick
[css-page-floats] Mostly editorial comments
liam   Tue, 18 Aug 2015 14:29:43 -0400

www-style > August 2015 > 0164.html

Received on Tuesday, 18 August 2015 18:29:45 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

I think most or all of these comments are editorial, so i didn't split them up into multiple messages. Section 5, Deferring Floats, starts out with the assertion, [[ A page float can be deferred to another fragmentation container than where the float anchor is placed. ]] Does this mean that an implementation has the flexibility to defer floats, or that users can control whether floats are deferred/ I think from the following paragraph it means the latter, but then why is the first paragraph there? Suggest removing the first paragraph. "This new property is instroduced" should name the property, e.g. "The float-defer property controls what happens when floats are deferred:" The description of a negative integer value could possibly be clearer :-) I _think_ it's trying to say that negative values count backwards from the last framentainer, with -1 being the last one, -2 being the next-to-last, and so on. It also needs to say what happens if N is less than -(total number of fragmentainers + 1) and also what happens if the fragmentainer referred to is earlier in the document -- e.g. we're formatting the third fragmentainer and we get to a request to put a float in the 2nd fragmentainer. In 7, "This property pushes a float in opposite direction of the where it has been floated with float." should be (i think) "This property pushes a float in the direction opposite to which it has been floated with float." but opposite could mean, up instead of down, or it could mean horizontally instead of vertically. The examples suggest the first of those meanings is intended (e.g. float: left; moves a block horizontally and potentially to the left, so we can only move it to the right. I don't understand how this would work if we move something in two directions at 0nce with float, as in some of the multi-column examples) "This property can only influence a page float along an axis it has been floated." probably means "This property can only influence a page float along an axis along which has been floated." As written it's not a grammatical sentence I think, or at least I can't parse it. Example 20: suppose contining-block-width is 300px and pull-quote-width is 100px. Then 50% is (300 - 100)px is 200px and moving the block by this much will not in fact center it. Or is the percentage applied twice/ What happens if there are two or more adjacent blocks floated and pushed by a percentage?? 8 stacking order We need to be able to override the float stacking order. See attachment 1 "pagefloat01.png" -- the left-hand situation isn't acceptable in general. Spanning of floats: Maybe this is specified elsewhere? See pagefloat02.png (attached) for examples of floated figures that (1) span two columns of text - not necessarily all columns if there are more than two - and (2) in the 2nd case, disrupt the flow of text, indicated with numerals in the grey boxes indicating text flow sequence. Liam -- Liam Quin, W3C XML Activity Lead; Digital publishing; HTML Accessibility
Re: [css-page-floats] Mostly editorial comments
Johannes Wilm   Wed, 19 Aug 2015 13:35:15 +0200

www-style > August 2015 > 0167.html

Received on Wednesday, 19 August 2015 11:35:44 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: liam@w3.org
Copied to: www-style@w3.org.

Hey, glad to have run into you last week! On Tue, Aug 18, 2015 at 8:29 PM, liam <liam@w3.org> wrote: > I think most or all of these comments are editorial, so i didn't split > them up into multiple messages. > > > Section 5, Deferring Floats, starts out with the assertion, > [[ > A page float can be deferred to another fragmentation container than where > the float anchor is placed. > ]] > > Does this mean that an implementation has the flexibility to defer floats, > or that users can control whether floats are deferred/ > > I think from the following paragraph it means the latter, but then why is > the first paragraph there? > fixed > > Suggest removing the first paragraph. > > "This new property is instroduced" should name the property, e.g. > "The float-defer property controls what happens when floats are deferred:" > > The description of a negative integer value could possibly be clearer :-) > I _think_ it's trying to say that negative values count backwards from the > last framentainer, with -1 being the last one, -2 being the next-to-last, > and so on. It also needs to say what happens if N is less than -(total > number of fragmentainers + 1) fixed > and also what happens if the fragmentainer referred to is earlier in the > document -- e.g. we're formatting the third fragmentainer and we get to a > request to put a float in the 2nd fragmentainer. > As far as I can see, it shouldn't be a problem to go back and add more page floats to a previous page/column/region, but that is because so far we are not doing reordering of the float stack (see below). > > In 7, > > "This property pushes a float in opposite direction of the where it has > been floated with float." > should be (i think) > "This property pushes a float in the direction opposite to which it has > been floated with float."i > fixed > but opposite could mean, up instead of down, or it could mean horizontally > instead of vertically. The examples suggest the first of those meanings is > intended (e.g. float: left; moves a block horizontally and potentially to > the left, so we can only move it to the right. I don't understand how this > would work if we move something in two directions at 0nce with float, as in > some of the multi-column examples) > so far we do not allow two dimensional floats, which is why this hasn't been an issue yet. > > "This property can only influence a page float along an axis it has been > floated." probably means > "This property can only influence a page float along an axis along which > has been floated." > As written it's not a grammatical sentence I think, or at least I can't > parse it. > I feel there is an "it" missing in the fixed version, otherwise fixed. > > Example 20: > suppose contining-block-width is 300px and pull-quote-width is 100px. > Then 50% is (300 - 100)px is 200px and moving the block by this much will > not in fact center it. Or is the percentage applied twice/ > What happens if there are two or more adjacent blocks floated and pushed > by a percentage?? > Good question. Should the percentage be "percentage of the remaining space after subtracting the space used by this and previous page floats? I am wondering whether it is a good idea to allow percentages for the float-defer value at all. > > 8 stacking order > We need to be able to override the float stacking order. > See attachment 1 "pagefloat01.png" -- the left-hand situation isn't > acceptable in general. > I can see how this can be useful, but so far we have gotten around it by specifying that it is a assumed that a page float fill the entire width/height by default in the direction it is not floated (so width=100% for top/bottom floats and height=100% for right/left floats). Are there any particular algorithms you would refer to that decide when stacking order should be changed automatically? Or do you have suggestions on how this should be specifiable manually? The situation you outline in pagefloat01.png would therefore mainly happen if b is a page float and a and c are column floats. If that were the case, b would be layouted first, so it would be placed on the top and the other two then in the remaining part of the column below. > > Spanning of floats: Maybe this is specified elsewhere? See pagefloat02.png > (attached) for examples of floated figures that (1) span two columns of > text - not necessarily all columns if there are more than two - and (2) in > the 2nd case, disrupt the flow of text, indicated with numerals in the grey > boxes indicating text flow sequence. > > Column spanning should have been moved to a new version of the multicol spec: https://drafts.csswg.org/css-multicol/ Thanks for the extensive feedback! -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Comments on Section 1 of the CSS Inline Spec
Stephen Zilles   Wed, 26 Aug 2015 10:32:51 +0000

www-style > August 2015 > 0301.html

Received on Wednesday, 26 August 2015 10:33:24 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, www-style@w3.org.

I did a quick review of Section 1 of the CSS Inline Specification some time ago, but as it is on the agenda for this F2F, I took a better look recently. The things that immediately strike me are: 1. There is no explicit way to set the alignment point for an object, especially a non-textual object, that is being aligned. This was the role of the "alignment-point" property in the prior proposal. This allows a relevant alignment point to be defined for a image that contains a glyph. Without this replaced elements are always aligned to their bottom margin edge. The "length" value of the "baseline-shift" longhand may help here, but the "percentage"values do not because they are relative to line-height which makes them useless for accurate postioning. If there is an "alignment-point" property (to be able to set it explicitly relative to the object being align (not relative to its parent)), then an "auto" value would mean set the alignment point to the position of the baseline to which you are aligning (in the object being aligned). A length or percentage value would set the alignment point relative to the bottom (content are, padding, margin?) of the object. In both cases, the alignment would be to place the alignment point at the position of the "alignment-baseline" in the parent. 2. This spec seems to be missing the "inherit" value of the 2.1 "vertical-align" property In CSS 2.1 the syntax is "baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage><http://www.w3.org/TR/CSS2/syndata.html#value-def-percentage> | <length><http://www.w3.org/TR/CSS2/syndata.html#value-def-length> | inherit<http://www.w3.org/TR/CSS2/cascade.html#value-def-inherit>" In the Inline Module the syntax (expanding the two "longhands") is "[<length><https://drafts.csswg.org/css-values-3/#length-value> |<https://drafts.csswg.org/css-values-3/#comb-one> <percentage><https://drafts.csswg.org/css-values-3/#percentage-value> |<https://drafts.csswg.org/css-values-3/#comb-one> sub |<https://drafts.csswg.org/css-values-3/#comb-one> super] || [baseline |<https://drafts.csswg.org/css-values-3/#comb-one> text-bottom |<https://drafts.csswg.org/css-values-3/#comb-one> alphabetic |<https://drafts.csswg.org/css-values-3/#comb-one> middle |<https://drafts.csswg.org/css-values-3/#comb-one> central |<https://drafts.csswg.org/css-values-3/#comb-one> mathematical |<https://drafts.csswg.org/css-values-3/#comb-one> text-top |<https://drafts.csswg.org/css-values-3/#comb-one>bottom |<https://drafts.csswg.org/css-values-3/#comb-one> center |<https://drafts.csswg.org/css-values-3/#comb-one> top]" 3. This new syntax allows the specification of both a baseline alignment and the specification of a shift. I presume, but the spec is not clear about this, that the baseline alignment is done first and the shift is done subsequent to that alignment. The spec should make this clear. 4. Why are "percentage" values of "baseline-shift" relative to the line height? It would seem that font-size would be more relevant. Font size is what is used to scale the baseline pos 5. With respect to Issue 3. It is clear that these alignments are not baseline alignments, but they were historically part of "vertical-align". It would seem to make sense for these three values (and an additional "auto" value) to be the values of a third shorthand, "subtree-alignment". The "auto" value would be the default and would mean use the "alignment-baseline" value. In this case the syntax would become "[[<length><https://drafts.csswg.org/css-values-3/#length-value> |<https://drafts.csswg.org/css-values-3/#comb-one> <percentage><https://drafts.csswg.org/css-values-3/#percentage-value> |<https://drafts.csswg.org/css-values-3/#comb-one> sub |<https://drafts.csswg.org/css-values-3/#comb-one> super] || [baseline |<https://drafts.csswg.org/css-values-3/#comb-one> text-bottom |<https://drafts.csswg.org/css-values-3/#comb-one> alphabetic |<https://drafts.csswg.org/css-values-3/#comb-one> middle |<https://drafts.csswg.org/css-values-3/#comb-one> central |<https://drafts.csswg.org/css-values-3/#comb-one> mathematical |<https://drafts.csswg.org/css-values-3/#comb-one> text-top]] && [<https://drafts.csswg.org/css-values-3/#comb-one>bottom |<https://drafts.csswg.org/css-values-3/#comb-one> center |<https://drafts.csswg.org/css-values-3/#comb-one> top]" This, however, would remove applying a "baseline-shift" to a "center"ed sub-tree. Is that something that is needed? Currently, shifts cannot be applied to sub-trees that are top or bottom positioned. 6. This section needs to define how the Line Box is content area is calculated if this module is to replace CSS2.1. Specifically it needs to show how "top" and "bottom" positioned sub-trees interact in determining the height of the Line Box. 7. This section also needs to specify how the baseline positions in the parent, the scaled baseline table, are calculated using "font-size" (of the parent) and the baseline table associated with the dominant baseline. These are the points to which the child alignment point can be aligned. 8. XSL-FO has a "use-script" value for "alignment-baseline" to provide a better version of "auto" making the default alignment baseline be script based. This may be a future version feature due to the difficulty of specifying what default baseline each script should use but it could be useful for authors. Steve Z
Re: Comments on Section 1 of the CSS Inline Spec
"L. David Baron"   Wed, 26 Aug 2015 12:57:31 +0200

www-style > August 2015 > 0302.html

Received on Wednesday, 26 August 2015 10:58:05 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: szilles@adobe.com
Copied to: www-style@w3.org, www-style@w3.org, www-style@w3.org.

On Wednesday 2015-08-26 10:32 +0000, Stephen Zilles wrote: > 2. This spec seems to be missing the "inherit" value of the 2.1 "vertical-align" property In general, we've avoided explicitly listing inherit, initial, etc., in post-level-2 modules. > 3. This new syntax allows the specification of both a baseline alignment and the specification of a shift. I presume, but the spec is not clear about this, that the baseline alignment is done first and the shift is done subsequent to that alignment. The spec should make this clear. > > > > 4. Why are "percentage" values of "baseline-shift" relative to the line height? It would seem that font-size would be more relevant. Font size is what is used to scale the baseline pos baseline-shift is one of the longhands resulting from splitting vertical-align into a shorthand. Percentage values of vertical-align have been relative to line-height since: http://www.w3.org/TR/REC-CSS1-961217#vertical-align so it's probably a little late to change it. :-) > 5. With respect to Issue 3. It is clear that these alignments are not baseline alignments, but they were historically part of "vertical-align". It would seem to make sense for these three values (and an additional "auto" value) to be the values of a third shorthand, "subtree-alignment". The "auto" value would be the default and would mean use the "alignment-baseline" value. In this case the syntax would become > "[[<length><https://drafts.csswg.org/css-values-3/#length-value> |<https://drafts.csswg.org/css-values-3/#comb-one> <percentage><https://drafts.csswg.org/css-values-3/#percentage-value> |<https://drafts.csswg.org/css-values-3/#comb-one> sub |<https://drafts.csswg.org/css-values-3/#comb-one> super] || [baseline |<https://drafts.csswg.org/css-values-3/#comb-one> text-bottom |<https://drafts.csswg.org/css-values-3/#comb-one> alphabetic |<https://drafts.csswg.org/css-values-3/#comb-one> middle |<https://drafts.csswg.org/css-values-3/#comb-one> central |<https://drafts.csswg.org/css-values-3/#comb-one> mathematical |<https://drafts.csswg.org/css-values-3/#comb-one> text-top]] && [<https://drafts.csswg.org/css-values-3/#comb-one>bottom |<https://drafts.csswg.org/css-values-3/#comb-one> center |<https://drafts.csswg.org/css-values-3/#comb-one> top]" > > This, however, would remove applying a "baseline-shift" to a "center"ed sub-tree. Is that something that is needed? Currently, shifts cannot be applied to sub-trees that are top or bottom positioned. There's some issue of compatibility with SVG here, though. (See also the history in https://bugzilla.mozilla.org/show_bug.cgi?id=308338 ; Gecko hasn't implemented the split yet.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: Comments on Section 1 of the CSS Inline Spec
"Tab Atkins Jr."   Wed, 2 Sep 2015 15:44:01 -0700

www-style > September 2015 > 0000.html

Received on Wednesday, 2 September 2015 22:44:47 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: dbaron@dbaron.org
Copied to: szilles@adobe.com, www-style@w3.org, www-style@w3.org, www-style@w3.org.

On Wed, Aug 26, 2015 at 3:57 AM, L. David Baron <dbaron@dbaron.org> wrote: > On Wednesday 2015-08-26 10:32 +0000, Stephen Zilles wrote: >> 2. This spec seems to be missing the "inherit" value of the 2.1 "vertical-align" property > > In general, we've avoided explicitly listing inherit, initial, etc., > in post-level-2 modules. This is codified practice - check out the paragraph near the end of <https://drafts.csswg.org/css-values/#component-types>. Explicitly listing such keywords is actually a specification mistake. ~TJ
[CSSWG][css-cascade-4] Last Call for Comments on CSS Cascading and Inheritance Level 4
fantasai   Tue, 8 Sep 2015 21:46:52 -0400

www-style > September 2015 > 0000.html

Received on Wednesday, 9 September 2015 01:47:35 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, whatwg@whatwg.org, public-webapps@w3.org, public-webapps@w3.org.

The CSS WG has published an updated Working Draft of the CSS Cascading and Inheritance Module Level 4 http://www.w3.org/TR/css-cascade-4/ This CSS module describes how to collate style rules and assign values to all properties on all elements by way of cascading (choosing a winning declaration among many) and inheritance (propagating values from parent to child). Additions to Level 4 include: * introduced the 'revert' keyword, which rolls back the cascade to the previous origin http://www.w3.org/TR/css-cascade-4/#default [This had been dropped from L3 due to lack of implementer interest; but there seems to be strong interest in it at this time.] e.g. * { all: revert; } /* wipe out the entire set of author-level styles */ * introduced supports() syntax for conditional @import rules http://www.w3.org/TR/css-cascade-4/#at-import e.g. @import "fallback.css" supports(not (display: flex)); Since we have no open or anticipated issues, we plan to transition this module to CR in about four weeks. We do encourage people to review the draft, particularly the changes since L3, and send us comments. Significant changes since the previous WD are listed at: http://www.w3.org/TR/2015/WD-css-cascade-4-20150908/#changes The editor's draft can be found at: https://drafts.csswg.org/css-cascade-4/ As always, please send any comments to <www-style@w3.org>, and please, prefix the subject line with [css-cascade-4] (as I did on this message). For the CSS WG, ~fantasai
[CSS-2015] Two minor comments on CSS Snapshot 2015
Momdo Nakamura   Wed, 14 Oct 2015 15:38:47 +0000

www-style > October 2015 > 0000.html

Received on Friday, 16 October 2015 09:58:04 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

1)In “Status of this document”, > When sending e-mail, please put the text “css-2010” in the subject, preferably like this: “[css-2010] …summary of comment…” The “css-2010” should be “css-2015”. 2)In section 2.1 (CSS Level 2) http://www.w3.org/TR/css-2015/#css-level-2 The informative paragraph in the CSS 2.1 spec says “The CSS Working Group encourages authors and implementors to reference CSS 2.2 (or its successor) instead of this document.” However, I cannot find any information related to CSS 2.2 from the corresponding subsection of CSS Snapshot 2015. I believe that we need to update the subsection. Best Regards, NAKAMURA, momdo
[css-values] Comments on Serialization of calc
Francois Remy   Wed, 17 Feb 2016 19:39:56 +0000

www-style > February 2016 > 0000.html

Received on Wednesday, 17 February 2016 19:40:26 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Hi Tab, Fantasai, Here are a few comments regarding the "calc" serialization section I just reviewed: https://drafts.csswg.org/css-values-3/#calc-serialize ----[0] Thanks for looking into this, you rock, as always! ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter? An alternative approach I would like to see investigated would be the following one: (a) define a canonical unit per type (length:px,time:s,...) or an ordered list of canonical units if needed (b) replace step 1 by something like "for each component of the sum, if it would possible to do so permanently, convert it into the canonical unit of the calc expression (specified values cannot be converted in a way that would make the conversion be invalid if the environment changes, computed values can)" This is a breaking change over your current approach which preserves 0vh for instance, while it would be converted to 0px in this case. We could add some additional condition that says that the validity of conversion is considered independently of the number put in front of the unit, which prevents 0 being an exception). ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though. Hope this helps, Francois
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Wed, 17 Feb 2016 15:48:09 -0800

www-style > February 2016 > 0000.html

Received on Wednesday, 17 February 2016 23:49:02 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: frremy@microsoft.com
Copied to: www-style@w3.org.

On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote: > Hi Tab, Fantasai, > > Here are a few comments regarding the "calc" serialization section I just reviewed: > https://drafts.csswg.org/css-values-3/#calc-serialize > > > ----[0] Thanks for looking into this, you rock, as always! > > > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter? It probably does need to be expanded on, but it's the same concept of "absolutization" that transforms em into px at computed-value time. > An alternative approach I would like to see investigated would be the following one: > (a) define a canonical unit per type (length:px,time:s,...) or an ordered list of canonical units if needed > (b) replace step 1 by something like "for each component of the sum, if it would possible to do so permanently, convert it into the canonical unit of the calc expression (specified values cannot be converted in a way that would make the conversion be invalid if the environment changes, computed values can)" > > This is a breaking change over your current approach which preserves 0vh for instance, while it would be converted to 0px in this case. We could add some additional condition that says that the validity of conversion is considered independently of the number put in front of the unit, which prevents 0 being an exception). Agree with this in general. And yeah, we'd combine based on units only, not values. > ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though. Yeah, this step is based on browsers' current behavior. I'd prefer to drop it if specifying fresh. ~TJ
Re: [css-values] Comments on Serialization of calc
"L. David Baron"   Wed, 17 Feb 2016 19:02:22 -0800

www-style > February 2016 > 0000.html

Received on Thursday, 18 February 2016 03:02:52 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: frremy@microsoft.com, www-style@w3.org.

On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote: > On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote: > > Hi Tab, Fantasai, > > > > Here are a few comments regarding the "calc" serialization section I just reviewed: > > https://drafts.csswg.org/css-values-3/#calc-serialize > > > > > > ----[0] Thanks for looking into this, you rock, as always! > > > > > > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter? > > It probably does need to be expanded on, but it's the same concept of > "absolutization" that transforms em into px at computed-value time. But it seems wrong to apply a computed-value type of process to a specified value. Perhaps what should be combined are *identical* units? Then, for computed values, many units will have been converted to identical units, but for specified values, they won't be. > > ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though. > > Yeah, this step is based on browsers' current behavior. I'd prefer to > drop it if specifying fresh. Gecko and Chromium don't do this. Testcase: <!DOCTYPE html> <p style="margin-left: calc(3px)"> <script> document.write(document.getElementsByTagName("p")[0].style.marginLeft); </script> or http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22margin-left%3A%20calc(3px)%22%3E%3C%2Fp%3E%0A%3Cscript%3E%0Adocument.write(document.getElementsByTagName(%22p%22)%5B0%5D.style.marginLeft)%3B%0A%3C%2Fscript%3E Perhaps what you were observing was part of the calc *computation* process rather than the calc *serialization* process? -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Thu, 10 Mar 2016 11:59:02 -0800

www-style > March 2016 > 0000.html

Received on Thursday, 10 March 2016 19:59:50 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: dbaron@dbaron.org
Copied to: frremy@microsoft.com, www-style@w3.org.

On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <dbaron@dbaron.org> wrote: > On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote: >> On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote: >> > Hi Tab, Fantasai, >> > >> > Here are a few comments regarding the "calc" serialization section I just reviewed: >> > https://drafts.csswg.org/css-values-3/#calc-serialize >> > >> > >> > ----[0] Thanks for looking into this, you rock, as always! >> > >> > >> > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter? >> >> It probably does need to be expanded on, but it's the same concept of >> "absolutization" that transforms em into px at computed-value time. > > But it seems wrong to apply a computed-value type of process to a > specified value. I'm not really sure what you mean by "computed-value type of process". Some units are combinable at specified-value time. 1in is always exactly equal to 96px, so "1in + 10px" can be losslessly converted to "106px" right away if you wanted. > Perhaps what should be combined are *identical* units? Then, for > computed values, many units will have been converted to identical > units, but for specified values, they won't be. This doesn't match any implementation. Chrome combines terms aggressively, based on what units are capable of being merged at a given time. Firefox doesn't combine at all - "calc(10px + 10px)" will return itself unchanged if you ask for specified value in current Firefox or IE. Chrome also resolves multiplication/division immediately, because it's always diving something by a constant value. I'd not sure what your suggestion would tend towards. Finally there's add/sub/mult/div of *numbers*. Firefox and Chrome do this eagerly - calc(1 + 2) will become calc(3) in specified style, calc(2/1) becomes calc(2). IE keeps it as written. So our current behaviors for specified-style calc() are: IE: Always returns what was written. Firefox: Returns what was written, except that it resolves any subexpressions whose arguments are purely numbers. Chrome: Eagerly resolves every subexpression that it can, based on specified-value-time data. Your suggestion is: Return what was written, but resolve any subexpressions with identical units. Right? (If I state it this way, it implies that calc(10px / 2) will stay that way. Is that what you intend?) I'd personally prefer Chrome's behavior, as it matches the behavior you get at computed-value and used-value time. (We can interpret your suggestion as also doing this, if we assume that comparable units are *only* turned into the "base" unit at computed-value time and above.) fantasai apparently prefers either IE's behavior or your suggested behavior, based on an IRC convo we're having right now. >> > ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though. >> >> Yeah, this step is based on browsers' current behavior. I'd prefer to >> drop it if specifying fresh. [snip] > Perhaps what you were observing was part of the calc *computation* > process rather than the calc *serialization* process? Ah, yeah, I was only looking at computed value there. I'm fine with preserving calc() through specified value, and only discarding it at computed-value time. I'll fix this part. ~TJ
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Thu, 10 Mar 2016 13:34:35 -0800

www-style > March 2016 > 0000.html

Received on Thursday, 10 March 2016 21:35:23 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: frremy@microsoft.com
Copied to: www-style@w3.org.

On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote: > It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? fantasai just pointed out that this is handled by CSSOM. As far as calc() is concerned they just combine together into a "<length> value", and CSSOM describes how to serialize length values (as px). Same for other units, like calc(1deg + 1rad). > Does order matter? Order doesn't matter in combining, but it does in serializing, and that's well-defined (alphabetical, with numbers first and percentages last). ~TJ
RE: [css-values] Comments on Serialization of calc
Francois Remy   Thu, 10 Mar 2016 21:42:09 +0000

www-style > March 2016 > 0000.html

Received on Thursday, 10 March 2016 21:42:41 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

> > It is also not clear to me what happens if we have calc(1cm + 1mm) vs > calc(1mm + 1cm). The units are compatible, but which one should we keep? > > fantasai just pointed out that this is handled by CSSOM. As far as > calc() is concerned they just combine together into a "<length> value", and > CSSOM describes how to serialize length values (as px). > Same for other units, like calc(1deg + 1rad). Perfect. I think we should reference that instead of making up a new term here, though. So, maybe we can say only identical units should be merged, because serialization is already going to take care of the process of converting them to the same unit, right? > > Does order matter? > > Order doesn't matter in combining, but it does in serializing, and that's well- > defined (alphabetical, with numbers first and percentages last). Makes sense, given your comment above.
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Thu, 10 Mar 2016 14:02:12 -0800

www-style > March 2016 > 0000.html

Received on Thursday, 10 March 2016 22:02:59 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: frremy@microsoft.com
Copied to: www-style@w3.org.

On Thu, Mar 10, 2016 at 1:42 PM, Francois Remy <frremy@microsoft.com> wrote: >> > It is also not clear to me what happens if we have calc(1cm + 1mm) vs >> calc(1mm + 1cm). The units are compatible, but which one should we keep? >> >> fantasai just pointed out that this is handled by CSSOM. As far as >> calc() is concerned they just combine together into a "<length> value", and >> CSSOM describes how to serialize length values (as px). >> Same for other units, like calc(1deg + 1rad). > > Perfect. I think we should reference that instead of making up a new term here, though. > > So, maybe we can say only identical units should be merged, because serialization is already going to take care of the process of converting them to the same unit, right? No, serialization won't automagically combine things, it just dictates what unit to use when they *do* get serialized. See my previous email to David where I explored what impls do at specified-value time. ~TJ
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Tue, 22 Mar 2016 17:39:53 -0700

www-style > March 2016 > 0000.html

Received on Wednesday, 23 March 2016 00:40:43 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: dbaron@dbaron.org
Copied to: frremy@microsoft.com, www-style@w3.org.

On Thu, Mar 10, 2016 at 11:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <dbaron@dbaron.org> wrote: >> On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote: >>> On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote: >>> > Hi Tab, Fantasai, >>> > >>> > Here are a few comments regarding the "calc" serialization section I just reviewed: >>> > https://drafts.csswg.org/css-values-3/#calc-serialize >>> > >>> > >>> > ----[0] Thanks for looking into this, you rock, as always! >>> > >>> > >>> > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter? >>> >>> It probably does need to be expanded on, but it's the same concept of >>> "absolutization" that transforms em into px at computed-value time. >> >> But it seems wrong to apply a computed-value type of process to a >> specified value. > > I'm not really sure what you mean by "computed-value type of process". > Some units are combinable at specified-value time. 1in is always > exactly equal to 96px, so "1in + 10px" can be losslessly converted to > "106px" right away if you wanted. > >> Perhaps what should be combined are *identical* units? Then, for >> computed values, many units will have been converted to identical >> units, but for specified values, they won't be. > > This doesn't match any implementation. Chrome combines terms > aggressively, based on what units are capable of being merged at a > given time. Firefox doesn't combine at all - "calc(10px + 10px)" will > return itself unchanged if you ask for specified value in current > Firefox or IE. > > Chrome also resolves multiplication/division immediately, because it's > always diving something by a constant value. I'd not sure what your > suggestion would tend towards. > > Finally there's add/sub/mult/div of *numbers*. Firefox and Chrome do > this eagerly - calc(1 + 2) will become calc(3) in specified style, > calc(2/1) becomes calc(2). IE keeps it as written. > > So our current behaviors for specified-style calc() are: > > IE: Always returns what was written. > Firefox: Returns what was written, except that it resolves any > subexpressions whose arguments are purely numbers. > Chrome: Eagerly resolves every subexpression that it can, based on > specified-value-time data. > > Your suggestion is: Return what was written, but resolve any > subexpressions with identical units. Right? (If I state it this way, > it implies that calc(10px / 2) will stay that way. Is that what you > intend?) > > I'd personally prefer Chrome's behavior, as it matches the behavior > you get at computed-value and used-value time. (We can interpret your > suggestion as also doing this, if we assume that comparable units are > *only* turned into the "base" unit at computed-value time and above.) > fantasai apparently prefers either IE's behavior or your suggested > behavior, based on an IRC convo we're having right now. Reminder that this is topic #1 at the call tomorrow, so if you haven't reviewed it and formed your opinion/arguments, we're gonna default to the standard CSSWG strategy: Tab does whatever he thinks best. ~TJ
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Thu, 24 Mar 2016 12:45:34 -0700

www-style > March 2016 > 0000.html

Received on Thursday, 24 March 2016 19:46:21 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: dbaron@dbaron.org
Copied to: frremy@microsoft.com, www-style@w3.org.

On Thu, Mar 10, 2016 at 11:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <dbaron@dbaron.org> wrote: >> Perhaps what should be combined are *identical* units? Then, for >> computed values, many units will have been converted to identical >> units, but for specified values, they won't be. > > This doesn't match any implementation. Chrome combines terms > aggressively, based on what units are capable of being merged at a > given time. Firefox doesn't combine at all - "calc(10px + 10px)" will > return itself unchanged if you ask for specified value in current > Firefox or IE. > > Chrome also resolves multiplication/division immediately, because it's > always diving something by a constant value. I'd not sure what your > suggestion would tend towards. > > Finally there's add/sub/mult/div of *numbers*. Firefox and Chrome do > this eagerly - calc(1 + 2) will become calc(3) in specified style, > calc(2/1) becomes calc(2). IE keeps it as written. > > So our current behaviors for specified-style calc() are: > > IE: Always returns what was written. > Firefox: Returns what was written, except that it resolves any > subexpressions whose arguments are purely numbers. > Chrome: Eagerly resolves every subexpression that it can, based on > specified-value-time data. > > Your suggestion is: Return what was written, but resolve any > subexpressions with identical units. Right? (If I state it this way, > it implies that calc(10px / 2) will stay that way. Is that what you > intend?) > > I'd personally prefer Chrome's behavior, as it matches the behavior > you get at computed-value and used-value time. (We can interpret your > suggestion as also doing this, if we assume that comparable units are > *only* turned into the "base" unit at computed-value time and above.) > fantasai apparently prefers either IE's behavior or your suggested > behavior, based on an IRC convo we're having right now. At the telcon yesterday, we decided that we *probably* wanted to go with: 1. All expressions with at least one "number" argument are resolved. (eg "1 + 2" => "3", "10px / 2" => "5px", "2 * (10px + 1em)" => "20px + 2em") 2. Terms with identical units are combined. (eg "10px + 15px" => "25px", but "10px + 1in" stays as written) This guarantees the calc() expression can be stored as a sum of unit'd values even at specified-value time, while still preserving author-specified units as much as possible, per usual behavior in specified values. (That is, if you type "width: 1in;", we preserve that in specified value, rather than converting it to the equivalent "width: 96px;".) The only dissenter was MS, who wished to review with their implementors and return with an answer next week. We'll make a final resolution next week and then I'll edit the spec accordingly. ~TJ
RE: [css-values] Comments on Serialization of calc
Greg Whitworth   Tue, 29 Mar 2016 00:57:39 +0000

www-style > March 2016 > 0000.html

Received on Tuesday, 29 March 2016 00:58:09 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, dbaron@dbaron.org
Copied to: frremy@microsoft.com, www-style@w3.org.

>The only dissenter was MS, who wished to review with their implementors >and return with an answer next week. This feels a little strongly worded IMO ;) I checked with the dev in question and while it won't be as trivial as you made it out to be we're ok with the change in principal. Thanks, Greg
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Wed, 30 Mar 2016 10:36:26 -0700

www-style > March 2016 > 0000.html

Received on Wednesday, 30 March 2016 17:37:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: gwhit@microsoft.com
Copied to: dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Mon, Mar 28, 2016 at 5:57 PM, Greg Whitworth <gwhit@microsoft.com> wrote: >>The only dissenter was MS, who wished to review with their implementors >>and return with an answer next week. > > This feels a little strongly worded IMO ;) > > I checked with the dev in question and while it won't be as trivial as you made it out to be we're ok with the change in principal. Apparently you're not, since Rossen just relitigated it on the call. :((((( Just to reiterate, in case people don't want to look a few messages upward, the proposal is that, at specified-value time, we: 1. Resolve all numeric expressions, leaving us with a sum of unit'd values. 2. Combine all identical units. > Rossen_: And I did. I'm the impl in charge of this and I have 3 pushbacks. 1 this won't be a trigger for us to impl 2) interop will be flacky at best and 3) this isn't helping authors. It's going to be hard for tools Let's run thru these. 1. I trust you that it's not trivial, but I suspect it's not *hard*, either. ^_^ At the bare minimum, you *must* be doing enough parsing to (a) figure out what the resolved type is, so you can validate grammar, and (b) resolve puredss-numeric expressions to see if there's any division by zero. If you've done that, you have all of the information and data structures necessary to serialize it in the requested way. 2. I don't understand. Really, I have *no clue* what part of this makes you think interop will be troublesome. The spec is quite explicit about how to serialize, and this proposal is making it more so. Can you give any example of what you think isn't defined? On the call, you asked about the serialization of "calc(9px + 8em + 5px + 3ex)". This is why I"m confused - the spec+proposal in completely explicit in how to serialize this. (The current spec makes the computed/used values completely defined, adding in the proposal makes specified value completely defined.) As a serialized value, this would be "calc(8em + 3ex + 14px)". (The unit ordering is defined by the spec as "number, then units in alpha order, then percent". I think current impls just have an arbitrary impl-specific ordering right now.) So is there anything else that still concerns you? 3. Yes, it is. Specifically, this helps us maintain a sane representation in the object-based OM we're designing. calc() as defined right now can always be represented as a sum of unit'd values, which means we can use a simple struct to represent it as an object. This is very easy to use and manipulate for authors. Having to preserve and represent an arbitrarily-complex math AST solely for specified-value objects, on the other hand, makes calc()s *way* harder to deal with. (And would mean authors have to write two *totally different codepaths* to handle specified-value calc() vs computed-value calc(), if they want to handle both .) (We will, eventually, have to deal with unit algebra, and thus have units of arbitrary complexity that can no longer be represented as a field in a struct. Shane and I have plans to deal with that, but we'll cross that bridge when we come to it, and even in that world, the *vast majority* of calc()s will be "simple" and still struct-friendly.) If you're talking solely about *string parsing* of calc()s, (a) we, as a group, aren't encouraging that, and are creating an API specifically to make that no longer necessary, and (b) this proposal *simplifies* string parsing by ensuring all calc()s are a simple sum of unit'd values. The only possible code that can be hurt by this change: * writes out calc()s and then re-parses its own values * using some extremely naive "parsing" code that requires the structure be *precisely* the same * only dealing with specified values ever (because computed/used simplify in *all* browsers) * and is IE-only (because everyone else simplifies specified values to some degree) So, between both the object-based OM and the string-based, this proposal simplifies generic handling and is useful for authors. Nothing I've said here is new; I discussed all of it last week, and it should be in the minutes. Again, we all tentatively agreed that the proposal is good, we were just waiting for MS folk to make sure there wasn't some "gotcha" that would make it hard for them. We got that on Monday, I was just waiting for the official resolution today before making the edits. Can we please resolve on this now? ~TJ
RE: [css-values] Comments on Serialization of calc
Rossen Atanassov   Fri, 1 Apr 2016 03:20:54 +0000

www-style > April 2016 > 0000.html

Received on Friday, 1 April 2016 03:21:27 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, gwhit@microsoft.com
Copied to: dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote: > > On Mon, Mar 28, 2016 at 5:57 PM, Greg Whitworth <gwhit@microsoft.com> > wrote: > >>The only dissenter was MS, who wished to review with their > >>implementors and return with an answer next week. > > > > This feels a little strongly worded IMO ;) > > > > I checked with the dev in question and while it won't be as trivial as you > made it out to be we're ok with the change in principal. > > Apparently you're not, since Rossen just relitigated it on the call. :((((( > > Just to reiterate, in case people don't want to look a few messages upward, > the proposal is that, at specified-value time, we: > > 1. Resolve all numeric expressions, leaving us with a sum of unit'd values. > 2. Combine all identical units. > > > Rossen_: And I did. I'm the impl in charge of this and I have 3 > > pushbacks. 1 this won't be a trigger for us to impl 2) interop will be > > flacky at best and 3) this isn't helping authors. It's going to be > > hard for tools "trigger" should've read "trivial" :) > Let's run thru these. > > 1. I trust you that it's not trivial, but I suspect it's not *hard*, either. ^_^ At > the bare minimum, you *must* be doing enough parsing to (a) figure out > what the resolved type is, so you can validate grammar, and (b) resolve > puredss-numeric expressions to see if there's any division by zero. If you've > done that, you have all of the information and data structures necessary to > serialize it in the requested way. It depends on what stage of the computation we're talking about. When serializing specified values we do quite a bit of work to preserve both user defined values and the order of the expression. This makes debugging and simply recognizing your calc expressions possible. Often times calc expressions are based on some user logic - "I know that my left and right margins are 10% and my left padding is 5px etc. thus I need to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses the meaning. For serializing computed values I'm not as concerned and actually prefer your current proposal. > 2. I don't understand. Really, I have *no clue* what part of this makes you > think interop will be troublesome. The spec is quite explicit about how to > serialize, and this proposal is making it more so. Can you give any example of > what you think isn't defined? > > On the call, you asked about the serialization of "calc(9px + 8em + 5px + > 3ex)". This is why I"m confused - the spec+proposal in completely explicit in > how to serialize this. (The current spec makes the computed/used values > completely defined, adding in the proposal makes specified value completely > defined.) As a serialized value, this would be "calc(8em + 3ex + 14px)". (The > unit ordering is defined by the spec as "number, then units in alpha order, > then percent". I think current impls just have an arbitrary impl-specific > ordering right now.) > > So is there anything else that still concerns you? Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, achieving interoperable solution will be possible, agreed. > 3. Yes, it is. Specifically, this helps us maintain a sane representation in the > object-based OM we're designing. calc() as defined right now can always be > represented as a sum of unit'd values, which means we can use a simple > struct to represent it as an object. > This is very easy to use and manipulate for authors. Having to preserve and > represent an arbitrarily-complex math AST solely for specified-value objects, > on the other hand, makes calc()s *way* harder to deal with. (And would > mean authors have to write two *totally different codepaths* to handle > specified-value calc() vs computed-value calc(), if they want to handle both .) Again, the concern I expressed applies to specified values. > (We will, eventually, have to deal with unit algebra, and thus have units of > arbitrary complexity that can no longer be represented as a field in a struct. > Shane and I have plans to deal with that, but we'll cross that bridge when we > come to it, and even in that world, the *vast majority* of calc()s will be > "simple" and still > struct-friendly.) > > If you're talking solely about *string parsing* of calc()s, (a) we, as a group, > aren't encouraging that, and are creating an API specifically to make that no > longer necessary, and (b) this proposal *simplifies* string parsing by ensuring > all calc()s are a simple sum of unit'd values. > > > The only possible code that can be hurt by this change: > > * writes out calc()s and then re-parses its own values > * using some extremely naive "parsing" code that requires the structure be > *precisely* the same > * only dealing with specified values ever (because computed/used simplify in > *all* browsers) > * and is IE-only (because everyone else simplifies specified values to some > degree) > > So, between both the object-based OM and the string-based, this proposal > simplifies generic handling and is useful for authors. > > > Nothing I've said here is new; I discussed all of it last week, and it should be in > the minutes. Again, we all tentatively agreed that the proposal is good, we > were just waiting for MS folk to make sure there wasn't some "gotcha" that > would make it hard for them. We got that on Monday, I was just waiting for > the official resolution today before making the edits. > > Can we please resolve on this now? Sure, if as a group we agree that this is the best path forward ^_^
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Fri, 1 Apr 2016 12:47:38 -0700

www-style > April 2016 > 0000.html

Received on Friday, 1 April 2016 19:48:25 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: Rossen.Atanassov@microsoft.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov <Rossen.Atanassov@microsoft.com> wrote: > On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote: >> 1. I trust you that it's not trivial, but I suspect it's not *hard*, either. ^_^ At >> the bare minimum, you *must* be doing enough parsing to (a) figure out >> what the resolved type is, so you can validate grammar, and (b) resolve >> puredss-numeric expressions to see if there's any division by zero. If you've >> done that, you have all of the information and data structures necessary to >> serialize it in the requested way. > > It depends on what stage of the computation we're talking about. > > When serializing specified values we do quite a bit of work to preserve both user defined values and the order of the expression. This makes debugging and simply recognizing your calc expressions possible. > > Often times calc expressions are based on some user logic - "I know that my left and right margins are 10% and my left padding is 5px etc. thus I need to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses the meaning. While this may have some theoretical value, there are no authors in the wild today depending on this, as IE is the only browser that preserves things exactly. All other browsers simplify at least somewhat, so authors already have to deal with the fact that their input and output might not be identical (or else they're writing really broken code). And, as I argued down below, the object-based OM wants to represent values in a simple way, to help authors; preserving the math AST, while matching the input intent, makes the values *much* harder to manipulate in an API. > For serializing computed values I'm not as concerned and actually prefer your current proposal. Computed values are already well-defined and aren't in question at the moment. >> 2. I don't understand. Really, I have *no clue* what part of this makes you >> think interop will be troublesome. The spec is quite explicit about how to >> serialize, and this proposal is making it more so. Can you give any example of >> what you think isn't defined? >> >> On the call, you asked about the serialization of "calc(9px + 8em + 5px + >> 3ex)". This is why I"m confused - the spec+proposal in completely explicit in >> how to serialize this. (The current spec makes the computed/used values >> completely defined, adding in the proposal makes specified value completely >> defined.) As a serialized value, this would be "calc(8em + 3ex + 14px)". (The >> unit ordering is defined by the spec as "number, then units in alpha order, >> then percent". I think current impls just have an arbitrary impl-specific >> ordering right now.) >> >> So is there anything else that still concerns you? > > Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, achieving interoperable solution will be possible, agreed. This is confusing to me, since if unit order was your concern, that applies to calc()'s serialization at *all* value stages. It's definitely not something that only matters for specified value, so how was that the only stage that makes this concern you? >> 3. Yes, it is. Specifically, this helps us maintain a sane representation in the >> object-based OM we're designing. calc() as defined right now can always be >> represented as a sum of unit'd values, which means we can use a simple >> struct to represent it as an object. >> This is very easy to use and manipulate for authors. Having to preserve and >> represent an arbitrarily-complex math AST solely for specified-value objects, >> on the other hand, makes calc()s *way* harder to deal with. (And would >> mean authors have to write two *totally different codepaths* to handle >> specified-value calc() vs computed-value calc(), if they want to handle both .) > > Again, the concern I expressed applies to specified values. The thing you are replying to is entirely about specified values. I mention computed values only in passing. >> Can we please resolve on this now? > > Sure, if as a group we agree that this is the best path forward ^_^ You are the only person disagreeing with this. The group agreed on it last week but deferred the resolution, you objected to it this week and blocked the resolution. That's why I'm asking you if we can resolve on this. ~TJ
RE: [css-values] Comments on Serialization of calc
Francois Remy   Fri, 1 Apr 2016 17:09:04 -0700

www-style > April 2016 > 0000.html

Received on Monday, 4 April 2016 15:24:09 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, Rossen.Atanassov@microsoft.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] > On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov > <Rossen.Atanassov@microsoft.com> wrote: > > On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote: > >> 1. I trust you that it's not trivial, but I suspect it's not *hard*, > >> either. ^_^ At the bare minimum, you *must* be doing enough parsing > >> to (a) figure out what the resolved type is, so you can validate > >> grammar, and (b) resolve puredss-numeric expressions to see if > >> there's any division by zero. If you've done that, you have all of > >> the information and data structures necessary to serialize it in the > requested way. > > > > It depends on what stage of the computation we're talking about. > > > > When serializing specified values we do quite a bit of work to preserve both > user defined values and the order of the expression. This makes debugging > and simply recognizing your calc expressions possible. > > > > Often times calc expressions are based on some user logic - "I know that > my left and right margins are 10% and my left padding is 5px etc. thus I need > to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses > the meaning. > > While this may have some theoretical value, there are no authors in the wild > today depending on this, as IE is the only browser that preserves things > exactly. All other browsers simplify at least somewhat, so authors already > have to deal with the fact that their input and output might not be identical > (or else they're writing really broken code). > > And, as I argued down below, the object-based OM wants to represent > values in a simple way, to help authors; preserving the math AST, while > matching the input intent, makes the values *much* harder to manipulate in > an API. > > > For serializing computed values I'm not as concerned and actually prefer > your current proposal. > > Computed values are already well-defined and aren't in question at the > moment. > > >> 2. I don't understand. Really, I have *no clue* what part of this > >> makes you think interop will be troublesome. The spec is quite > >> explicit about how to serialize, and this proposal is making it more > >> so. Can you give any example of what you think isn't defined? > >> > >> On the call, you asked about the serialization of "calc(9px + 8em + > >> 5px + 3ex)". This is why I"m confused - the spec+proposal in > >> completely explicit in how to serialize this. (The current spec > >> makes the computed/used values completely defined, adding in the > >> proposal makes specified value completely > >> defined.) As a serialized value, this would be "calc(8em + 3ex + > >> 14px)". (The unit ordering is defined by the spec as "number, then > >> units in alpha order, then percent". I think current impls just have > >> an arbitrary impl-specific ordering right now.) > >> > >> So is there anything else that still concerns you? > > > > Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, > achieving interoperable solution will be possible, agreed. > > This is confusing to me, since if unit order was your concern, that applies to > calc()'s serialization at *all* value stages. It's definitely not something that > only matters for specified value, so how was that the only stage that makes > this concern you? > > >> 3. Yes, it is. Specifically, this helps us maintain a sane > >> representation in the object-based OM we're designing. calc() as > >> defined right now can always be represented as a sum of unit'd > >> values, which means we can use a simple struct to represent it as an > object. > >> This is very easy to use and manipulate for authors. Having to > >> preserve and represent an arbitrarily-complex math AST solely for > >> specified-value objects, on the other hand, makes calc()s *way* > >> harder to deal with. (And would mean authors have to write two > >> *totally different codepaths* to handle specified-value calc() vs > >> computed-value calc(), if they want to handle both .) > > > > Again, the concern I expressed applies to specified values. > > The thing you are replying to is entirely about specified values. I mention > computed values only in passing. > > >> Can we please resolve on this now? > > > > Sure, if as a group we agree that this is the best path forward ^_^ > > You are the only person disagreeing with this. The group agreed on it last > week but deferred the resolution, you objected to it this week and blocked > the resolution. That's why I'm asking you if we can resolve on this. > > ~TJ Just as a small note: since we all mostly refactor shorthands/longhands, reformat colors, and drop comments+whitespace already, I ("webdev / cssom user" me) am still under the impression that the "preserving what the author wrote" boat sailed a long time ago. That being said, I can understand the argument that choosing this serialization for the specified style reveals details about how css is handled now, which we may never or more difficulty change in the future if we want to. I don't see this as a strong blocker, but I acknowledge the point. I think this is Rossen's main concern, here. Unrelated: Tab, you might want to take a look at this one, because Chrome is acting weird on that one: https://jsfiddle.net/09dbr7m6/2/
RE: [css-values] Comments on Serialization of calc
Francois Remy   Fri, 1 Apr 2016 17:09:04 -0700

www-style > April 2016 > 0000.html

Received on Saturday, 2 April 2016 00:09:37 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, Rossen.Atanassov@microsoft.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] > On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov > <Rossen.Atanassov@microsoft.com> wrote: > > On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote: > >> 1. I trust you that it's not trivial, but I suspect it's not *hard*, > >> either. ^_^ At the bare minimum, you *must* be doing enough parsing > >> to (a) figure out what the resolved type is, so you can validate > >> grammar, and (b) resolve puredss-numeric expressions to see if > >> there's any division by zero. If you've done that, you have all of > >> the information and data structures necessary to serialize it in the > requested way. > > > > It depends on what stage of the computation we're talking about. > > > > When serializing specified values we do quite a bit of work to preserve both > user defined values and the order of the expression. This makes debugging > and simply recognizing your calc expressions possible. > > > > Often times calc expressions are based on some user logic - "I know that > my left and right margins are 10% and my left padding is 5px etc. thus I need > to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses > the meaning. > > While this may have some theoretical value, there are no authors in the wild > today depending on this, as IE is the only browser that preserves things > exactly. All other browsers simplify at least somewhat, so authors already > have to deal with the fact that their input and output might not be identical > (or else they're writing really broken code). > > And, as I argued down below, the object-based OM wants to represent > values in a simple way, to help authors; preserving the math AST, while > matching the input intent, makes the values *much* harder to manipulate in > an API. > > > For serializing computed values I'm not as concerned and actually prefer > your current proposal. > > Computed values are already well-defined and aren't in question at the > moment. > > >> 2. I don't understand. Really, I have *no clue* what part of this > >> makes you think interop will be troublesome. The spec is quite > >> explicit about how to serialize, and this proposal is making it more > >> so. Can you give any example of what you think isn't defined? > >> > >> On the call, you asked about the serialization of "calc(9px + 8em + > >> 5px + 3ex)". This is why I"m confused - the spec+proposal in > >> completely explicit in how to serialize this. (The current spec > >> makes the computed/used values completely defined, adding in the > >> proposal makes specified value completely > >> defined.) As a serialized value, this would be "calc(8em + 3ex + > >> 14px)". (The unit ordering is defined by the spec as "number, then > >> units in alpha order, then percent". I think current impls just have > >> an arbitrary impl-specific ordering right now.) > >> > >> So is there anything else that still concerns you? > > > > Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, > achieving interoperable solution will be possible, agreed. > > This is confusing to me, since if unit order was your concern, that applies to > calc()'s serialization at *all* value stages. It's definitely not something that > only matters for specified value, so how was that the only stage that makes > this concern you? > > >> 3. Yes, it is. Specifically, this helps us maintain a sane > >> representation in the object-based OM we're designing. calc() as > >> defined right now can always be represented as a sum of unit'd > >> values, which means we can use a simple struct to represent it as an > object. > >> This is very easy to use and manipulate for authors. Having to > >> preserve and represent an arbitrarily-complex math AST solely for > >> specified-value objects, on the other hand, makes calc()s *way* > >> harder to deal with. (And would mean authors have to write two > >> *totally different codepaths* to handle specified-value calc() vs > >> computed-value calc(), if they want to handle both .) > > > > Again, the concern I expressed applies to specified values. > > The thing you are replying to is entirely about specified values. I mention > computed values only in passing. > > >> Can we please resolve on this now? > > > > Sure, if as a group we agree that this is the best path forward ^_^ > > You are the only person disagreeing with this. The group agreed on it last > week but deferred the resolution, you objected to it this week and blocked > the resolution. That's why I'm asking you if we can resolve on this. > > ~TJ Just as a small note: since we all mostly refactor shorthands/longhands, reformat colors, and drop comments+whitespace already, I ("webdev / cssom user" me) am still under the impression that the "preserving what the author wrote" boat sailed a long time ago. That being said, I can understand the argument that choosing this serialization for the specified style reveals details about how css is handled now, which we may never or more difficulty change in the future if we want to. I don't see this as a strong blocker, but I acknowledge the point. I think this is Rossen's main concern, here. Unrelated: Tab, you might want to take a look at this one, because Chrome is acting weird on that one: https://jsfiddle.net/09dbr7m6/2/
Re: [css-values] Comments on Serialization of calc
fantasai   Sat, 2 Apr 2016 12:22:44 -0400

www-style > April 2016 > 0000.html

Received on Saturday, 2 April 2016 16:23:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, Rossen.Atanassov@microsoft.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote: > > While this may have some theoretical value, there are no authors in > the wild today depending on this, as IE is the only browser that > preserves things exactly. All other browsers simplify at least > somewhat, so authors already have to deal with the fact that their > input and output might not be identical (or else they're writing > really broken code). This is a very misleading statement. Mozilla only simplifies numerical factors, so in fact IE and Mozilla's behaviors are very close and preserve almost everything. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4029 Also, Rossen's concern (which I share) is not just about what authors are depending on right now (given lack of interop between Blink/Webkit and IE/FF, it's probably not much), but what would be useful for them to have going into the future. And I agree that for computed style we should collapse as much as possible. (In fact, the Computed Value line is generally represented as a tuple of percentage and length, which then serializes out as calc() if it's got non-zero values in both.) I won't object to collapsing identical units in specified styles, but I'm not convinced that saves us a whole lot, especially given we plan to add multiplication and division by units and keywords into the calc expressions at some point in the future -- which are not things that can be simplified away so easily. In any case, as I noted in the minutes of the telecon you're referencing, I would prefer we got author feedback on this issue. ~fantasai
Re: [css-values] Comments on Serialization of calc
Alan Stearns   Sat, 2 Apr 2016 17:00:07 +0000

www-style > April 2016 > 0000.html

Received on Saturday, 2 April 2016 17:00:40 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net, jackalmage@gmail.com, Rossen.Atanassov@microsoft.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On 4/2/16, 9:22 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote: >On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote: >> >> While this may have some theoretical value, there are no authors in >> the wild today depending on this, as IE is the only browser that >> preserves things exactly. All other browsers simplify at least >> somewhat, so authors already have to deal with the fact that their >> input and output might not be identical (or else they're writing >> really broken code). > >This is a very misleading statement. Mozilla only simplifies numerical >factors, so in fact IE and Mozilla's behaviors are very close and >preserve almost everything. > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4029 > >Also, Rossen's concern (which I share) is not just about what authors >are depending on right now (given lack of interop between Blink/Webkit >and IE/FF, it's probably not much), but what would be useful for them >to have going into the future. Given that we’re talking about debugging, lack of browser interop may be a more minor factor than is usual. If one or more browsers have more useful debugging tool behavior, it’s likely that people *do* depend on it if it happens to be the browser they choose to start development in. Thanks, Alan
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Sat, 2 Apr 2016 20:55:43 -0700

www-style > April 2016 > 0000.html

Received on Sunday, 3 April 2016 03:56:31 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: Rossen.Atanassov@microsoft.com, gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Sat, Apr 2, 2016 at 9:22 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote: >> While this may have some theoretical value, there are no authors in >> the wild today depending on this, as IE is the only browser that >> preserves things exactly. All other browsers simplify at least >> somewhat, so authors already have to deal with the fact that their >> input and output might not be identical (or else they're writing >> really broken code). > > > This is a very misleading statement. Mozilla only simplifies numerical > factors, so in fact IE and Mozilla's behaviors are very close and > preserve almost everything. > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4029 "Everything" and "almost everything" are *very* different when you're talking about preserving intent. There's a big difference between "a third of this 40px margin" and "13.33333333px". > Also, Rossen's concern (which I share) is not just about what authors > are depending on right now (given lack of interop between Blink/Webkit > and IE/FF, it's probably not much), but what would be useful for them > to have going into the future. Which I addressed in my further points. > I won't object to collapsing identical units in specified styles, > but I'm not convinced that saves us a whole lot, especially given > we plan to add multiplication and division by units and keywords > into the calc expressions at some point in the future -- which are > not things that can be simplified away so easily. I already addressed this in my earlier message. ~TJ
Re: [css-values] Comments on Serialization of calc
Alan Stearns   Sun, 3 Apr 2016 17:33:24 +0000

www-style > April 2016 > 0000.html

Received on Sunday, 3 April 2016 17:33:55 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, fantasai.lists@inkedblade.net
Copied to: Rossen.Atanassov@microsoft.com, gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On 4/2/16, 8:55 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >On Sat, Apr 2, 2016 at 9:22 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > >> I won't object to collapsing identical units in specified styles, >> but I'm not convinced that saves us a whole lot, especially given >> we plan to add multiplication and division by units and keywords >> into the calc expressions at some point in the future -- which are >> not things that can be simplified away so easily. > >I already addressed this in my earlier message. Could you reiterate or expand on this for my benefit? I read through the thread again and have missed this part. My current understanding is that since the current simplification proposal is not the most aggressive one, there are current cases that will not be able to be expressed in the simple OM - something like calc(1em + 1ex + 10px). Is that correct? Are there other edge cases that will need a more complicated OM? What’s the fallback plan for things that don’t fit into the simple calc type? (either now if I’m correct that there are edge cases or in the future when we allow more complex calc expressions) Thanks, Alan
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Mon, 4 Apr 2016 16:27:41 -0700

www-style > April 2016 > 0000.html

Received on Monday, 4 April 2016 23:28:28 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: stearns@adobe.com
Copied to: fantasai.lists@inkedblade.net, Rossen.Atanassov@microsoft.com, gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <stearns@adobe.com> wrote: > On 4/2/16, 8:55 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > >>On Sat, Apr 2, 2016 at 9:22 AM, fantasai <fantasai.lists@inkedblade.net> wrote: >> >>> I won't object to collapsing identical units in specified styles, >>> but I'm not convinced that saves us a whole lot, especially given >>> we plan to add multiplication and division by units and keywords >>> into the calc expressions at some point in the future -- which are >>> not things that can be simplified away so easily. >> >>I already addressed this in my earlier message. > > Could you reiterate or expand on this for my benefit? I read through the thread again and have missed this part. Me talking about the object-based OM, where a "list of unit'd values" makes the OM sane and easy to work with, but an AST is not. > My current understanding is that since the current simplification proposal is not the most aggressive one, there are current cases that will not be able to be expressed in the simple OM - something like calc(1em + 1ex + 10px). Is that correct? No, that works just fine. Can you elaborate on why you think that would be problematic? It sounds like there's a pretty fundamental disconnect in what people are thinking about, which might explain the confusion. > Are there other edge cases that will need a more complicated OM? No, Level 3 calc() is 100% representable in the object-based OM, assuming structural simplifications (that result in equivalent expressions) are allowed. > What’s the fallback plan for things that don’t fit into the simple calc type? (either now if I’m correct that there are edge cases or in the future when we allow more complex calc expressions) Our current plan is to simplify things into three categories: * a sum of unit'd values, as today * a sum of values with complex units, to handle mult/division by unit'd values * a sum of inverses of sums of complex units, to handle division by sums of unit'd values As far as I can tell, that's the best we can do; it keeps things as simple as possible for the common case (everything you can do today), and makes things as simple as possible for the next most-common case (dividing a unit by a unit) Alternately, if having two types of "complex" expressions is too much, just hang an AST off the object to represent the latter two categories. More work for anyone trying to process things, but it's at only *one* type of work. Unsure if the tradeoffs are better. ~TJ
RE: [css-values] Comments on Serialization of calc
Rossen Atanassov   Tue, 5 Apr 2016 01:08:30 +0000

www-style > April 2016 > 0000.html

Received on Tuesday, 5 April 2016 01:09:01 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Fri, Apr 01, 2016 at 12:47:38, Tab Atkins Jr. wrote: > > On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov > <Rossen.Atanassov@microsoft.com> wrote: > > On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote: > >> 1. I trust you that it's not trivial, but I suspect it's not *hard*, > >> either. ^_^ At the bare minimum, you *must* be doing enough parsing > >> to (a) figure out what the resolved type is, so you can validate > >> grammar, and (b) resolve puredss-numeric expressions to see if > >> there's any division by zero. If you've done that, you have all of > >> the information and data structures necessary to serialize it in the > requested way. > > > > It depends on what stage of the computation we're talking about. > > > > When serializing specified values we do quite a bit of work to preserve > both user defined values and the order of the expression. This makes > debugging and simply recognizing your calc expressions possible. > > > > Often times calc expressions are based on some user logic - "I know that > my left and right margins are 10% and my left padding is 5px etc. thus I need > to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses > the meaning. > > While this may have some theoretical value, there are no authors in the wild > today depending on this, as IE is the only browser that preserves things > exactly. All other browsers simplify at least somewhat, so authors already > have to deal with the fact that their input and output might not be identical > (or else they're writing really broken code). So you're saying, let's not make things good for authors just because there's only one browser that currently does that? (which is not really the case because Firefox does very little simplification). > And, as I argued down below, the object-based OM wants to represent > values in a simple way, to help authors; preserving the math AST, while > matching the input intent, makes the values *much* harder to manipulate in > an API. Even with typed, object-based OM why would the order of values and operands make it *much* harder to manipulate in an API? > > For serializing computed values I'm not as concerned and actually prefer > your current proposal. > > Computed values are already well-defined and aren't in question at the > moment. Great. > >> 2. I don't understand. Really, I have *no clue* what part of this > >> makes you think interop will be troublesome. The spec is quite > >> explicit about how to serialize, and this proposal is making it more > >> so. Can you give any example of what you think isn't defined? > >> > >> On the call, you asked about the serialization of "calc(9px + 8em + > >> 5px + 3ex)". This is why I"m confused - the spec+proposal in > >> completely explicit in how to serialize this. (The current spec > >> makes the computed/used values completely defined, adding in the > >> proposal makes specified value completely > >> defined.) As a serialized value, this would be "calc(8em + 3ex + > >> 14px)". (The unit ordering is defined by the spec as "number, then > >> units in alpha order, then percent". I think current impls just have > >> an arbitrary impl-specific ordering right now.) > >> > >> So is there anything else that still concerns you? > > > > Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, > achieving interoperable solution will be possible, agreed. > > This is confusing to me, since if unit order was your concern, that applies to > calc()'s serialization at *all* value stages. It's definitely not something that > only matters for specified value, so how was that the only stage that makes > this concern you? Nobody expect to see an EM value type on a computed property and understands that by the time cascade runs such values are already computed as PX, % or AUTO, hence the name *computed*. Specified values are ones the authors *specify*, thus it is a good idea to show them what they specified in the matched rules of an element. > >> 3. Yes, it is. Specifically, this helps us maintain a sane > >> representation in the object-based OM we're designing. calc() as > >> defined right now can always be represented as a sum of unit'd > >> values, which means we can use a simple struct to represent it as an > object. > >> This is very easy to use and manipulate for authors. Having to > >> preserve and represent an arbitrarily-complex math AST solely for > >> specified-value objects, on the other hand, makes calc()s *way* > >> harder to deal with. (And would mean authors have to write two > >> *totally different codepaths* to handle specified-value calc() vs > >> computed-value calc(), if they want to handle both .) > > > > Again, the concern I expressed applies to specified values. > > The thing you are replying to is entirely about specified values. I mention > computed values only in passing. Yes and the distinction is important enough so others can understand why one makes a lot more sense than the other. > >> Can we please resolve on this now? > > > > Sure, if as a group we agree that this is the best path forward ^_^ > > You are the only person disagreeing with this. The group agreed on it last > week but deferred the resolution, you objected to it this week and blocked > the resolution. That's why I'm asking you if we can resolve on this. I see at least fantasai sharing this concern. Cheers, Rossen
Re: [css-values] Comments on Serialization of calc
Alan Stearns   Tue, 5 Apr 2016 01:27:33 +0000

www-style > April 2016 > 0000.html

Received on Tuesday, 5 April 2016 01:28:03 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: fantasai.lists@inkedblade.net, Rossen.Atanassov@microsoft.com, gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On 4/4/16, 4:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <stearns@adobe.com> wrote: > >> My current understanding is that since the current simplification proposal is not the most aggressive one, there are current cases that will not be able to be expressed in the simple OM - something like calc(1em + 1ex + 10px). Is that correct? > >No, that works just fine. Can you elaborate on why you think that >would be problematic? It sounds like there's a pretty fundamental >disconnect in what people are thinking about, which might explain the >confusion. For some reason I though part of the motivation for simplification was to get down to the sum of *two* unit’d values. But now I’m past that misconception - thanks. > >> Are there other edge cases that will need a more complicated OM? > >No, Level 3 calc() is 100% representable in the object-based OM, >assuming structural simplifications (that result in equivalent >expressions) are allowed. So in the current Typed OM proposal there’s *one* px value, which is why you’d need to combine (10px + 10px). Without that simplification, you’d need to be able to handle arbitrary numbers of px-unit values. But if those two 10px values are actually separate things the author has specified, wouldn’t it be better for the Typed OM to retain them as separate entities in the specified style? Say I had a number of calc values in a pattern like: calc(10px + 300px + 10px) calc(10px + 10% + 10px) calc(10px + 50% + 10px) And I decided that the first 10px component needed to be replaced by 1em. I’d prefer an API that let me remove a 10px value and add a 1em value, instead of subtracting 10 from the combined px component and adding 1 to the combined em component. If I had some additional values like calc(10px + 50px) and wanted to replace all of the 10px components with 1em, I’d be out of luck with the current Typed OM - I wouldn’t know which calcs had one 10px value and which had two. Would it really be that hard to represent and work with multiple values of the same unit? Thanks, Alan
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Tue, 5 Apr 2016 11:29:42 -0700

www-style > April 2016 > 0000.html

Received on Tuesday, 5 April 2016 18:30:36 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: Rossen.Atanassov@microsoft.com
Copied to: gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Mon, Apr 4, 2016 at 6:08 PM, Rossen Atanassov <Rossen.Atanassov@microsoft.com> wrote: > On Fri, Apr 01, 2016 at 12:47:38, Tab Atkins Jr. wrote: >> On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov >> <Rossen.Atanassov@microsoft.com> wrote: >> > On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote: >> >> 1. I trust you that it's not trivial, but I suspect it's not *hard*, >> >> either. ^_^ At the bare minimum, you *must* be doing enough parsing >> >> to (a) figure out what the resolved type is, so you can validate >> >> grammar, and (b) resolve puredss-numeric expressions to see if >> >> there's any division by zero. If you've done that, you have all of >> >> the information and data structures necessary to serialize it in the >> requested way. >> > >> > It depends on what stage of the computation we're talking about. >> > >> > When serializing specified values we do quite a bit of work to preserve >> both user defined values and the order of the expression. This makes >> debugging and simply recognizing your calc expressions possible. >> > >> > Often times calc expressions are based on some user logic - "I know that >> my left and right margins are 10% and my left padding is 5px etc. thus I need >> to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses >> the meaning. >> >> While this may have some theoretical value, there are no authors in the wild >> today depending on this, as IE is the only browser that preserves things >> exactly. All other browsers simplify at least somewhat, so authors already >> have to deal with the fact that their input and output might not be identical >> (or else they're writing really broken code). > > So you're saying, let's not make things good for authors just because there's only one browser that currently does that? (which is not really the case because Firefox does very little simplification). This is a dishonest gloss, and I don't appreciate it. I did a quick survey of Stack Overflow, and there appear to be *zero* questions about this, despite the fact that Chrome/WebKit do relatively substantial simplification (and have been doing so for nearly three years <https://bugs.chromium.org/p/chromium/issues/detail?id=243610>). I can't find a single bug in the Chromium bug tracker about this, either. So to a first approximation, it appears that authors don't care about this. I already described the set of circumstances that have to be met in order for the ordering to matter; they're extremely hard to meet. Absent that one super-corner-case (which is *extremely fragile* anyway and shouldn't be encouraged), whether to simplify/reorder or not appears to be solely an aesthetic/theoretical-purity preference. Since authors don't seem to care, this narrows even further, to solely an aesthetic/theoretical-purity preference *from implementors*. Per the priority of constituencies, that sort of preference is *very easy* to override with even a small benefit to authors, and the better behavior of the object-based OM is precisely such a benefit. >> And, as I argued down below, the object-based OM wants to represent >> values in a simple way, to help authors; preserving the math AST, while >> matching the input intent, makes the values *much* harder to manipulate in >> an API. > > Even with typed, object-based OM why would the order of values and operands make it *much* harder to manipulate in an API? I explained why - the object-based OM is shaped like <https://drafts.css-houdini.org/css-typed-om/#calclength>, which does not preserve ordering, multiplicity of identical units, or numeric factors. This shape is *really easy* to work with, however - you can trivially read, write, and manipulate it in script. It's easier than a list of {value, unit} pairs (which preserve ordering/multiplicity), and *much* easier than a *tree structure* of {value, unit} pairs (which preserve numeric factors as well). >> >> 2. I don't understand. Really, I have *no clue* what part of this >> >> makes you think interop will be troublesome. The spec is quite >> >> explicit about how to serialize, and this proposal is making it more >> >> so. Can you give any example of what you think isn't defined? >> >> >> >> On the call, you asked about the serialization of "calc(9px + 8em + >> >> 5px + 3ex)". This is why I"m confused - the spec+proposal in >> >> completely explicit in how to serialize this. (The current spec >> >> makes the computed/used values completely defined, adding in the >> >> proposal makes specified value completely >> >> defined.) As a serialized value, this would be "calc(8em + 3ex + >> >> 14px)". (The unit ordering is defined by the spec as "number, then >> >> units in alpha order, then percent". I think current impls just have >> >> an arbitrary impl-specific ordering right now.) >> >> >> >> So is there anything else that still concerns you? >> > >> > Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, >> achieving interoperable solution will be possible, agreed. >> >> This is confusing to me, since if unit order was your concern, that applies to >> calc()'s serialization at *all* value stages. It's definitely not something that >> only matters for specified value, so how was that the only stage that makes >> this concern you? > > Nobody expect to see an EM value type on a computed property and understands that by the time cascade runs such values are already computed as PX, % or AUTO, hence the name *computed*. Specified values are ones the authors *specify*, thus it is a good idea to show them what they specified in the matched rules of an element. This appears to be a non-sequitur? I was wondering why your concern was about interoperability of specified-value unit ordering, given that the other value stages *also* have unit-ordering concerns. It doesn't really matter, as you appear to be happy about this, I was just confused. >> >> 3. Yes, it is. Specifically, this helps us maintain a sane >> >> representation in the object-based OM we're designing. calc() as >> >> defined right now can always be represented as a sum of unit'd >> >> values, which means we can use a simple struct to represent it as an >> object. >> >> This is very easy to use and manipulate for authors. Having to >> >> preserve and represent an arbitrarily-complex math AST solely for >> >> specified-value objects, on the other hand, makes calc()s *way* >> >> harder to deal with. (And would mean authors have to write two >> >> *totally different codepaths* to handle specified-value calc() vs >> >> computed-value calc(), if they want to handle both .) >> > >> > Again, the concern I expressed applies to specified values. >> >> The thing you are replying to is entirely about specified values. I mention >> computed values only in passing. > > Yes and the distinction is important enough so others can understand why one makes a lot more sense than the other. What I mean is, the section quoted above that I originally wrote was providing justification for this specified-values proposal. Your response ignored that and just responded to the mention of computed values. It didn't even respond to the content of that mention, which was about how presenting a different OM for specified values and computed values was bad for authors. >> >> Can we please resolve on this now? >> > >> > Sure, if as a group we agree that this is the best path forward ^_^ >> >> You are the only person disagreeing with this. The group agreed on it last >> week but deferred the resolution, you objected to it this week and blocked >> the resolution. That's why I'm asking you if we can resolve on this. > > I see at least fantasai sharing this concern. Her objection also ignored my previous arguments. :/ ~TJ
Re: [css-values] Comments on Serialization of calc
"Tab Atkins Jr."   Tue, 5 Apr 2016 11:39:13 -0700

www-style > April 2016 > 0000.html

Received on Tuesday, 5 April 2016 18:40:00 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: stearns@adobe.com
Copied to: fantasai.lists@inkedblade.net, Rossen.Atanassov@microsoft.com, gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Mon, Apr 4, 2016 at 6:27 PM, Alan Stearns <stearns@adobe.com> wrote: > On 4/4/16, 4:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >>On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <stearns@adobe.com> wrote: >>> Are there other edge cases that will need a more complicated OM? >> >>No, Level 3 calc() is 100% representable in the object-based OM, >>assuming structural simplifications (that result in equivalent >>expressions) are allowed. > > So in the current Typed OM proposal there’s *one* px value, which is why you’d need to combine (10px + 10px). Without that simplification, you’d need to be able to handle arbitrary numbers of px-unit values. > > But if those two 10px values are actually separate things the author has specified, wouldn’t it be better for the Typed OM to retain them as separate entities in the specified style? Say I had a number of calc values in a pattern like: > > calc(10px + 300px + 10px) > calc(10px + 10% + 10px) > calc(10px + 50% + 10px) > > And I decided that the first 10px component needed to be replaced by 1em. I’d prefer an API that let me remove a 10px value and add a 1em value, instead of subtracting 10 from the combined px component and adding 1 to the combined em component. You're talking about modifying stylesheets at an editor level. That's more or less out-of-scope. I don't think there's a similar concern for normal scripts altering values. And as I said in an earlier email, for this case to be valid at all, it requires the script in question to be the only thing setting values, and depending on the specified style to function as a proxy for whatever data-structure their code is assuming. Again, such code doesn't appear to exist. I cannot find a single StackOverflow question about this, nor a single Chromium bug, despite Chrome/WebKit doing an *even stronger* form of simplification for nearly three years. If this was actually a problem for a non-negligible number of authors, we'd have *some* evidence of people complaining about it, but there doesn't appear to be any. > If I had some additional values like calc(10px + 50px) and wanted to replace all of the 10px components with 1em, I’d be out of luck with the current Typed OM - I wouldn’t know which calcs had one 10px value and which had two. > > Would it really be that hard to represent and work with multiple values of the same unit? Yes, you need an *entirely different* structure. As I just said in my response to Rossen, to preserve ordering/multiplicity, you instead need a list of {value, unit} objects. To preserve numeric factors as well (which is *definitely required* according to the argument you're making) we actually need a *tree structure* of {value, unit} objects. Walking a tree in order to determine anything about the structure of your calc seems greatly overcomplicated for the (apparently vast majority of) authors that don't care about the structure and just want to tweak some values. ~TJ
Re: [css-values] Comments on Serialization of calc
Shane Stephens   Tue, 05 Apr 2016 21:15:22 +0000

www-style > April 2016 > 0000.html

Received on Tuesday, 5 April 2016 21:16:01 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, stearns@adobe.com
Copied to: fantasai.lists@inkedblade.net, Rossen.Atanassov@microsoft.com, gwhit@microsoft.com, dbaron@dbaron.org, frremy@microsoft.com, www-style@w3.org.

On Wed, Apr 6, 2016 at 4:44 AM Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Mon, Apr 4, 2016 at 6:27 PM, Alan Stearns <stearns@adobe.com> wrote: > > On 4/4/16, 4:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > >>On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <stearns@adobe.com> wrote: > >>> Are there other edge cases that will need a more complicated OM? > >> > >>No, Level 3 calc() is 100% representable in the object-based OM, > >>assuming structural simplifications (that result in equivalent > >>expressions) are allowed. > > > > So in the current Typed OM proposal there’s *one* px value, which is why > you’d need to combine (10px + 10px). Without that simplification, you’d > need to be able to handle arbitrary numbers of px-unit values. > > > > But if those two 10px values are actually separate things the author has > specified, wouldn’t it be better for the Typed OM to retain them as > separate entities in the specified style? Say I had a number of calc values > in a pattern like: > > > > calc(10px + 300px + 10px) > > calc(10px + 10% + 10px) > > calc(10px + 50% + 10px) > > > > And I decided that the first 10px component needed to be replaced by > 1em. I’d prefer an API that let me remove a 10px value and add a 1em value, > instead of subtracting 10 from the combined px component and adding 1 to > the combined em component. > > You're talking about modifying stylesheets at an editor level. That's > more or less out-of-scope. I don't think there's a similar concern > for normal scripts altering values. And as I said in an earlier > email, for this case to be valid at all, it requires the script in > question to be the only thing setting values, and depending on the > specified style to function as a proxy for whatever data-structure > their code is assuming. > Right - the Typed OM is for regularized access to style information. It's more valuable to be able to treat lengths as a dictionary of units than it is to exactly preserve the author's string input. For example, the Web Animations polyfill (github.com/web-animations/web-animations-next) parses lengths into precisely this sort of structure because it needs to work off something regular to correctly perform interpolation. Having said that, I'm not sure that there's a strict requirement that string serialization matches typed OM behavior - it's just nicer if everything produces 'the same' sorts of strings at some level (and it means implementations don't have to carry around extra information solely for the legacy string serialization). Cheers, -Shane
[css-grid] A few comments
Christian Biesinger   Thu, 21 Apr 2016 10:51:25 -0400

www-style > April 2016 > 0000.html

Received on Thursday, 21 April 2016 14:52:14 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Hi there! I've done a read through the entire grid spec now, and would like to offer some feedback: 1) There's a few places where named grid areas are used, and it comes in three different flavors -- it can be part of a string (grid-template-areas), it can be quoted using square brackets (grid-template-{columns,rows}) or can be unquoted (grid-area, grid-row and others). I was wondering if it would be easier for authors if they shared a more common format? E.g. always require quoting in [brackets], including the grid-template-areas ("[foo] [foo]")? 2) 10.1.3 in the last example (https://drafts.csswg.org/css-grid/#common-uses-named-lines): As this example comes before the normative definition of how the spans are resolved, maybe it would be helpful if the comment elaborated a little bit further on how the "span text 2" line is selected. E.g.: "Look forward from the start and take the second line named text" 3) 12.5 (https://drafts.csswg.org/css-grid/#grid-align): Why are these properties (justify-content, align-content) fully defined here, instead of referring to css-align like the previous two sections do, for justify-{self,items} and align-{self, items}? Thanks, -Christian
Re: [css-grid] A few comments
"Tab Atkins Jr."   Thu, 21 Apr 2016 14:52:55 -0700

www-style > April 2016 > 0000.html

Received on Thursday, 21 April 2016 21:53:42 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: cbiesinger@google.com
Copied to: www-style@w3.org.

On Thu, Apr 21, 2016 at 7:51 AM, Christian Biesinger <cbiesinger@google.com> wrote: > Hi there! > > I've done a read through the entire grid spec now, and would like to > offer some feedback: > > 1) There's a few places where named grid areas are used, and it comes > in three different flavors -- it can be part of a string > (grid-template-areas), it can be quoted using square brackets > (grid-template-{columns,rows}) or can be unquoted (grid-area, grid-row > and others). > > I was wondering if it would be easier for authors if they shared a > more common format? E.g. always require quoting in [brackets], > including the grid-template-areas ("[foo] [foo]")? The [foo] syntax is for declaring named lines, not areas - you'll notice that in the big ascii-art 'grid' clause, you can do both. > 2) 10.1.3 in the last example > (https://drafts.csswg.org/css-grid/#common-uses-named-lines): > As this example comes before the normative definition of how the spans > are resolved, maybe it would be helpful if the comment elaborated a > little bit further on how the "span text 2" line is selected. E.g.: > "Look forward from the start and take the second line named text" Sure, fixed. > 3) 12.5 (https://drafts.csswg.org/css-grid/#grid-align): Why are these > properties (justify-content, align-content) fully defined here, > instead of referring to css-align like the previous two sections do, > for justify-{self,items} and align-{self, items}? Oversight, mostly. It *should* just defer to Align the same as the previous sections. The little bits of normative clarification here need to be moved to Align. ~TJ
[css-color] Comment from APA
Janina Sajka   Wed, 3 Aug 2016 19:51:17 -0400

www-style > August 2016 > 0000.html

Received on Wednesday, 3 August 2016 23:51:43 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org
Copied to: public-apa@w3.org, cooper@w3.org.

Colleagues: The Accessible Platform Architectures (APA) Working Group requests addition of the following section to the specification css color module level 4 https://www.w3.org/tr/css-color-4/ Accessibility Impact Statement Content authors should be mindful of requirements on color contrast as expressed in WCAG 2.0 Success Criterion 1.4.3: http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html . See also : https://www.w3.org/WAI/perspectives/contrast.html It is particularly important to be mindful of this requirement when a transparency is present because automated measurement is not available to quantatively and correctly judge whether sufficient contrast is being provided, thus requiring application of informed human judgement on a case by case basis. APA Consensus Documentation This request is a consensus position of APA as documented at: http://lists.w3.org/Archives/Public/public-apa/2016Aug/0008.html Janina Sajka, APA Chair -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
Re: [css-color] Comment from APA
"Tab Atkins Jr."   Thu, 4 Aug 2016 11:36:15 -0700

www-style > August 2016 > 0000.html

Received on Thursday, 4 August 2016 18:44:10 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: janina@rednote.net
Copied to: www-style@w3.org, public-apa@w3.org, cooper@w3.org.

On Wed, Aug 3, 2016 at 4:51 PM, Janina Sajka <janina@rednote.net> wrote: > Colleagues: > > The Accessible Platform Architectures (APA) Working Group requests > addition of the following section to the specification css color module > level 4 > https://www.w3.org/tr/css-color-4/ > > Accessibility Impact Statement > > Content authors should be mindful of requirements on color > contrast as expressed in WCAG 2.0 Success Criterion 1.4.3: > http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html > > . See also : > https://www.w3.org/WAI/perspectives/contrast.html > > It is particularly important to be mindful of this requirement when a > transparency is present because automated measurement is not available > to quantatively and correctly judge whether sufficient contrast is being > provided, thus requiring application of informed human judgement on a > case by case basis. > > APA Consensus Documentation > > This request is a consensus position of APA as documented at: > http://lists.w3.org/Archives/Public/public-apa/2016Aug/0008.html Note that we already have a similar reference to WCAG 1.4.1: <https://www.w3.org/TR/css-color-4/#notes>. Just making sure y'all really want to be adding an additional a11y notice to the spec, or if y'all missed the existing one and it's enough. ~TJ
Re: [css-color] Comment from APA
Janina Sajka   Thu, 11 Aug 2016 12:53:15 -0400

www-style > August 2016 > 0000.html

Received on Thursday, 11 August 2016 16:53:40 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org, public-apa@w3.org, cooper@w3.org.

Hello, Tab: Thank you for your note. We have two responses below. Tab Atkins Jr. writes: > On Wed, Aug 3, 2016 at 4:51 PM, Janina Sajka <janina@rednote.net> wrote: > > Colleagues: > > > > The Accessible Platform Architectures (APA) Working Group requests > > addition of the following section to the specification css color module > > level 4 > > https://www.w3.org/tr/css-color-4/ > > > > Accessibility Impact Statement > > > > Content authors should be mindful of requirements on color > > contrast as expressed in WCAG 2.0 Success Criterion 1.4.3: > > http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html > > > > . See also : > > https://www.w3.org/WAI/perspectives/contrast.html > > > > It is particularly important to be mindful of this requirement when a > > transparency is present because automated measurement is not available > > to quantatively and correctly judge whether sufficient contrast is being > > provided, thus requiring application of informed human judgement on a > > case by case basis. > > > > APA Consensus Documentation > > > > This request is a consensus position of APA as documented at: > > http://lists.w3.org/Archives/Public/public-apa/2016Aug/0008.html > > Note that we already have a similar reference to WCAG 1.4.1: > <https://www.w3.org/TR/css-color-4/#notes>. Just making sure y'all 1.) We appreciate the reference at 3.1. However, the current language covers only one concern. We have added additional concerns that we believe should be explicitly called out. So, perhaps the language at 3.1 might combine what you already have about not relying on color alone with our comment on contrast, and especially on the need for human verification of sufficient contrast when transparencies are involved. > really want to be adding an additional a11y notice to the spec, or if > y'all missed the existing one and it's enough. > 2.) We would still request an Accessibility Impact statement which should, certainly, link to 3.1 in this case. We are tending toward asking for Accessibility Impact statements in all W3C specifications. There are several reasons we are tending toward this approach including most especially assisting whatever individual on a developer team who draws the responsibility for checking accessibility. We are inclined we should ease that task rather than asking people to ferret out relevant accessibility considerations from the entire specification. We expect this approach will be among those we discuss at the upcoming TPAC session on improving horizontal review. Janina > ~TJ -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
[css-tables] Editorial: General Comments
fantasai   Mon, 5 Sep 2016 17:36:51 -0400

www-style > September 2016 > 0000.html

Received on Monday, 5 September 2016 22:22:02 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

A few things up front here... 1. “layouted” is not a word. The past tense of the verb “lay out” is “laid out”. 2. While turning entire sentence predicates into terminology might be the hip thing to do in some circles, in CSS we try to define individual nouns and (in some cases) verbs for cross-linking. Not only does this look less absurd to the lay person, it gives more grammatical flexibility to the referrer, focuses highlights on concept-distinguishing content words rather than their surrounding sentence-context words, reduces the need for passive construction (and thereby the wordiness of sentences in general), and reduces the effort necessary to commit terminology to memory and keep its consistent throughout the spec. For example, # A table-root element is said to be <dfn>layouted in collapsed-borders mode</dfn> is better as | The table is in <dfn>collapsed-borders mode</dfn> 3. CSS layout operates on boxes, not elements. A table-root element is not layouted. A table is laid out. The only sections of your spec that should be talking about elements are the ones discussing boxes being generated from elements, and those making comparisons or examples with HTML *elements*. See https://drafts.csswg.org/css-display/#intro 4. The format for defining values of a CSS property is <dl dfn-for="property-name" dfn-type="value"> <dt><dfn>value</dfn> <dd>... <dt><dfn>other-value</dfn> <dd>... </dl> This will facilitate correct formatting and cross-linking. Also, using <dl> instead of a bunch of mixed-up paragraphs with inline definitions makes the spec easier to scan. Unlike blog posts, which are meant to be read like normal literature, CSS specs must be designed equally for scanning and perusing. Part of this effort is in the styling (it is one of the reasons our specs don't have a “subtle” look to them), but part of it is also in how we as spec editors structure our content. 5. The word “may” MUST NOT appear in your spec except when describing optional behavior. For example, # Lengths may not be negative. should be | Negative values are invalid. or some such unequivocal statement. ~fantasai
RE: [css-tables] Editorial: General Comments
Francois Remy   Wed, 7 Sep 2016 18:09:34 +0000

www-style > September 2016 > 0000.html

Received on Wednesday, 7 September 2016 18:10:14 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net, gwhit@microsoft.com
Copied to: www-style@w3.org, www-style@w3.org.

Thanks again fantasai for the review. Here is the "disposition of comments" :-) ======================================================================= > 1. “layouted” is not a word. The past tense of the verb “lay out” is “laid out”. Oh no, I thought the official approval to make up new words came pre-packaged with joining the csswg, I am disappointed ;-) I reluctantly fixed it, though :-) ======================================================================= > 2. A table-root element is said to be <dfn>layouted in collapsed-borders mode</dfn> Mostly fixed. The prose could be simplified further but that will do, for now. ======================================================================= > 3. CSS layout operates on boxes, not elements. Uh, yeah. Fixed. ======================================================================= > 4. The format for defining values of a CSS property is <dl dfn-for="property-name" dfn-type="value"> <dt><dfn>value</dfn> <dd>... <dt><dfn>other-value</dfn> <dd>... </dl> Where do you think this applies? Caption-sides? ======================================================================= > 5. Invalid use of “may” Fixed. That is a text copy-pasted from CSS 2.1 though, you might want to fix the source. http://www.w3.org/TR/CSS21/tables.html#propdef-border-spacing That's all for now
Draft checklist for accessibility of technology, comment by 17 March
Janina Sajka   Mon, 20 Feb 2017 21:48:21 +0000

www-style > February 2017 > 0000.html

Received on Monday, 20 February 2017 21:48:42 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: w3c-wai-ig@w3.org, chairs@w3.org, spec-prod@w3.org, public-html@w3.org, www-style@w3.org, public-svg-wg@w3.org, public-webauthn@w3.org, www-international@w3.org, www-tag@w3.org, public-digipub-ig@w3.org, public-payments-wg@w3.org, public-secondscreen@w3.org, w3t@w3.org, public-wot-wg@w3.org.

The Accessible Platform Architectures (APA) Working Group is developing a checklist to guide specification developers in the features needed to ensure their technology enables accessibility to people with disabilities. This is to address not only content markup languages that describe primary content, but also styling languages that impact presentation, APIs that enable manipulation and data interchange, and protocols that tie it all together. Like similar checklists addressing Internationalization, Privacy, and Security, this would enable self-review as a first stage in the "horizontal review" process of ensuring W3C specifications have broad applicability. Using it should reduce effort in providing basic accessibility coverage, and it will aid early identification of more complex issues that may need direct exploration with the APA WG. The draft checklist is available at: http://w3c.github.io/pfwg/wtag/checklist.html This draft is not yet complete, in particular expanded details about each checklist item are yet to be added, but it shows how APA approaches its horizontal review responsibility. We request review from a variety of stakeholders, including accessibility groups who identify user needs and specification developers who might use this checklist. The following questions may help guide your review: * Is it understandable how these checkpoints apply to technologies? * Is this format useful in considering accessibility needs during technology development? * Would this guidance help inform your interaction with the APA WG on horizontal review? * Are the checkpoints relevant to *specifications*? * Are there any missing types of issues specs might have that impact accessibility? * Within each section, are there any missing checkpoints? * Is the overall order logical? We appreciate review of this first version by 17 March 2017, so the APA WG can incorporate feedback in time for an updated draft in April. Comments can be sent: * by email to public-apa@w3.org, * as an issue at https://github.com/w3c/pfwg/issues, * or as pull requests against the master branch at https://github.com/w3c/pfwg/blob/master/wtag/checklist.html Janina Sajka, APA WG Chair Michael Cooper, APA WG W3C Staff Contact
[css-flexbox] Disposition of Comments
fantasai   Tue, 14 Mar 2017 22:02:01 -0700

www-style > March 2017 > 0000.html

Received on Wednesday, 15 March 2017 05:02:46 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org
Copied to: dholbert@mozilla.com, cbiesinger@google.com.

I've finished compiling the Disposition of Comments for Flexbox: https://drafts.csswg.org/css-flexbox/issues-cr-20160526 There are several issues that would be nice to get feedback on: 1. Static position not following hypothetical position loses use cases https://github.com/w3c/csswg-drafts/issues/401 2. Absolute ratios technically impossible with padding/margin https://github.com/w3c/csswg-drafts/issues/316 3. Percentage margins and intrinsic sizing https://github.com/w3c/csswg-drafts/issues/347 4. Definiteness of auto-basis flex items not interoperable https://lists.w3.org/Archives/Public/www-style/2017Jan/0068.html (I'm actually really concerned about #2, since it means we're failing to fulfill the feature's intention, and I hope we can still fix it somehow...) ~fantasai
[CSSWG][css-align] Last Call for Comments on CSS Box Alignment Level 3
fantasai   Mon, 15 May 2017 14:25:02 -0400

www-style > May 2017 > 0000.html

Received on Monday, 15 May 2017 18:27:54 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, www-international@w3.org, public-review-announce@w3.org, public-css-a11y@w3.org, public-apa@w3.org.

The CSS WG has published its hopefully last Working Draft of the CSS Box Alignment Module Level 3: https://www.w3.org/TR/css-align-3/ This module contains the features of CSS relating to the alignment of boxes within their containers in the various CSS box layout models: block layout, table layout, flex layout, and grid layout. This is the last call for comments, as we plan to request a transition to CR in two weeks unless issues are brought up or anyone specifically requests more time for review. Wrt i18n, the alignment values are expressed in flow-relative (writing-mode responsive) directional terms, so we don't anticipate any problems there. Baseline alignment, despite its simple invocation, is very complicated, however: we've done our best to handle all the various script and writing mode combinations. Wrt a11y, the alignment values just shift things around slightly on the screen; there is no visual reordering or re-arrangement of any elements, nor any interaction, color, or time-based considerations, so we don't anticipate any a11y issues. Changes since the last draft are listed at: https://www.w3.org/TR/2017/WD-css-align-3-20170515/#changes and consist of some syntactic changes, deferring features to L4, and some minor behavioral tweaks. If you need more time to review, please let us know. Otherwise, please send any comments to our mailing list, <www-style@w3.org>, prefixed with [css-align] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[CSSWG][mediaqueries-4] Last Call for Comments on Media Queries Level 4
Florian Rivoal   Sat, 20 May 2017 00:11:05 +0900

www-style > May 2017 > 0000.html

Received on Friday, 19 May 2017 15:11:38 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, public-review-announce@w3.org
Copied to: www-international@w3.org, public-css-a11y@w3.org, public-apa@w3.org.

The CSS WG has published its hopefully last Working Draft of Media Queries Level 4: https://www.w3.org/TR/mediaqueries-4/ Media Queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered. They are used in the CSS @media rule to conditionally apply styles to a document, and in various other contexts and languages, such as HTML and Javascript. Level 4 extends and supersedes the features defined in Media Queries Level 3. It brings significant improvements on the syntax, and a shift from using media types to finer-grained media features. This is the last call for comments, as we plan to request a transition to CR at the end of June unless issues are brought up or anyone specifically requests more time for review. Significant changes since Media Queries 3 are listed at: https://www.w3.org/TR/2017/WD-mediaqueries-4-20170519/#changes-2012 Please review the draft, and send any comments to this mailing list, <www-style@w3.org>, prefixed with [mediaqueries-4] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, —Florian Rivoal
[CSSWG] Minutes Tokyo F2F Thu 2017-04-20 Part IV: Japanese Vertical Text Design Awards & Miscellaneous Commentary [css-fonts][css-rhythm]
fantasai   Fri, 26 May 2017 20:54:15 -0400

www-style > May 2017 > 0000.html

Received on Saturday, 27 May 2017 00:54:49 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Tate Yoko Award --------------- - The working group hosted a talk by Kobayashi-sensei on the challenges in typography currently faced by the Japanese language community. - Many different use cases were raised for further thought by the working group. - The group appreciated Kobayashi-sensei's insights and expertise on line rhythm, kanbun, step-sizing, and other topics. - Suggested to add class=advisement to paragraph recommending authors use 'font-variant-*' instead of 'font-feature-settings'; this point also needs better evangelism among the authoring community. ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics Scribe: none Tate Yoko Award =============== Note: The speaker for this topic was not minuted; just the working group's side discussions on his talk. <bobbytung> Tate Yoko Award: https://tategaki.github.io/awards/ <ChrisL> When kerning is enabled, the OpenType kern feature is enabled (for vertical text runs the vkrn feature is enabled instead). <fantasai> Should be using font-kerning, not font-feature-settings <fantasai> https://www.w3.org/TR/css-fonts-3/#font-kerning-prop <fantasai> font-kerning should handle this correctly. [would make sense to check the source code] [Yanagi-san will contact the authors and clarify what they're doing] hiroshi: (shows http://wwwc.webcrow.jp/) hiroshi: The problem is that some browser put "より" on the right side instead of center. fantasai: Maybe bug of Chrome. (seems Edge works ok) fantasai: Hopefully can be fixed <fantasai> https://www.w3.org/TR/css-writing-modes-3/#inline-alignment <fantasai> https://www.w3.org/TR/css-writing-modes-3/#text-baselines <fantasai> “In vertical typographic mode, the central baseline is used as the dominant baseline when text-orientation is mixed or upright. Otherwise the alphabetic baseline is used. ” Rossen: Please let us know if there are bugs. <Florian> Having checked with the author, he was not aware of the higher level properties that should be used (when possible) instead of font-feature-settings. Maybe there is an effort to do on the readability of the spec of this topic <fantasai> Florian, maybe can use class=advisement, but I think it's mostly a problem of implementations releasing font-feature-settings before higher-level features were implemented <Florian> fantasai: agree about both points <BogdanBrinza> Microsoft Edge public bug tracker: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/ zhengxu: Would like to know the priority of font rendering issues. <astearns> currently looking at a requirement for line breaking at punctuation - not covered by CSS at the moment <astearns> in this case, if a line is too long to fit with no punctuation to break at, there are several possibilities. Maybe you'd break the line as normal, maybe you'd have overflow (to scroll to) <astearns> the way it's currently done is to add a <br> in the markup after the punctuation <Rossen> It sounds like they want to have the ability to size the block to the size of the minimum line length <astearns> maximum, yes <fantasai> yeah, we can do that <fantasai> max-content <Rossen> basically <div style="width: min-inline-content;">... <Rossen> max-content will result in the longest possible line <Rossen> min-content will result in the longest possible word... <fantasai> It's also important to know whether this is a stylistic choice or if it's based on type of content (prose vs poetry) <Rossen> so if we assume that they need the shortest line then we don't have that <fantasai> they're using the longest one afaict <fantasai> the breaks are at punctuation <fantasai> and are forced <Rossen> right, but then he said something about wanting to have smaller size of the container and use scrolling... <fantasai> Yeah, that's nowrap :) <fantasai> We can solve this case <fantasai> Once we have line break transformations correctly implemented, we can even handle the choice between the left and right cases at the style level <fantasai> by using pre-lines for the right case, and normal for the left (white-space) [wrt complaint that italics is not interoperable for vertical text] <fantasai> https://lists.w3.org/Archives/Public/www-style/2013Jul/0065.html <fantasai> “RESOLVED: Leave synthesis of italics in vertical text undefined.” [discussion of mousewheel direction] <fantasai> fantasai: if the primary scroll direction and page progression direction are not derived from the same information, pages will print/scroll incorrectly when they are designed for scrolling/printing <fantasai> (mousewheel should follow primary scroll direction / page progression direction) <BogdanBrinza> Edge supports -ms-scroll-translation property with vertical-to-horizontal value: https://msdn.microsoft.com/en-us/library/hh973361(v=vs.85).aspx <dbaron> But there seems to be a desire for horizontal scrolling, but only once various UI issues (e.g., mousewheel) are fixed. <dbaron> is the page progression direction determined by writing-mode on the root? <dbaron> (and is there propagation from body to root?) <fantasai> yes <fantasai> body, actually <fantasai> because WebKit <fantasai> we take writing-mode and direction from body (or root if no body) to determine the scroll directions and page progression <astearns> so fantasai is saying we need more slashes? <dbaron> https://drafts.csswg.org/css-text/#propdef-text-transform says: <dbaron> full-width <dbaron> Puts all typographic character units in fullwidth form. If a character does not have a corresponding fullwidth form, it is left as is. This value is typically used to typeset Latin letters and digits as if they were ideographic characters. <dbaron> ... which seems like it ought to work here. <fantasai> we only trigger tate-chu-yoko on ascii digits, currently <fantasai> so there's an interaction here that's a bit tricky <fantasai> (originally we did any digits, but jdaggett wanted a simplification) <BogdanBrinza> https://blogs.windows.com/msedgedev/2016/08/11/edgebug-twitter/#rfzCkGZwfebJuxTA.97 <BogdanBrinza> ^ #EdgeBug <dbaron> florian talks about https://www.w3.org/Submission/CSJTUWT/ <dbaron> Florian's summary of the key part of Kobayashi-sensei's point was I think that the things that are most important for legibility in Japanese are line length and character spacing (related to character grid and line grid), and today they're all horrible on the Web <dbaron> (I should have tried to write it down right as he said it, though) <dbaron> jlreq is https://www.w3.org/TR/jlreq/ , for the record <tantek> who showed the dot-leader example on the screen? <dbaron> https://drafts.csswg.org/css-content/#leaders <dbaron> The current spec for Leaders feels more like a feature wishlist than a spec <astearns> Could you automatically shift the color over video continuously using blend modes? <myles> astearns: think of the perf <myles> astearns: and it would have to pierce through compositing layers making it expensive <astearns> it would make my eyes hurt to try to read shifting-color text anyway <myles> Yes <flackr> astearns, myles ^ it's not nice on the eyes, but seems to work in chrome at least <flackr> http://jsbin.com/faputep/edit?html,css,output <bobbytung> Should it be resolved with TTML? <myles> bobbytung: if the content uses TTML :P <BogdanBrinza> https://blogs.windows.com/msedgedev/2016/04/20/building-a-more-accessible-web-platform/#Iym2qYXS7kFCQydY.97 Section "Improved web legibility in high contrast" Rhythm discussion notes ----------------------- Scribe: fantasai - Current discussion is on rhythm - Koji is projecting a document with two columns that shows the text rhythm being kept when the text is interrupted by an image, the rhythm is not resumed, it is merely restarted as a result, the columns don't align across the gap. - Koji asserts that there are professional users for whom this is unacceptable - They would prefer to insert extra space to resume the rhythm - Koji also asserts that for casual users, they prefer to not insert extra space in order to resume the previous rhythm. - Kobayashi-sensei asserts that there are no such people. - He draws some content. - Says that the top and bottom of the page need to be aligned properly. - The drawing is of two columns or two facing pages. Problem is them not being aligned, the reason is because of inserted images. - (two interruptions in the text) - (in the middle, the text isn't aligned to the line grid) - If tried to align, the spacing before and after the image would be uneven. If there is just one column, don't do this. - This kind of adjustment is not done automatically in DPT software, can be done by setting fixed position for the middle? block of text - If you just have one column, being even is better; if you have two, lining up is better - Since it's not achieved so far in DTP, not requiring that Web does it but he wishes that we solved that problem. - If we did some kind of vertical justification by spreading the leftover space... Can't get into details, it's more complicated, so far hasn't been solved - Another problem is when you have cite-outs - You want to line up the sidenote with the thing being annotated, there is also this requirement. - In DTP software, they would draw a line and attach things to it. - (There are various names for these kinds of alignment) - If you go in inline direction, have problem of things lining up... justification is generally solved by DTP software. - Florian explains: this is a similar problem to justification, which is a mostly solved problem; the vertical equivalent isn't solved. - Kobayashi-sensei continues... - It's a problem worth solving, but also it's hard. - The desire to align the bottom edge of things is also strong. - But that might be different from print and web; on print it's really important, but on the Web less important maybe because we are scrolling. - Maybe we have one less constraint when playing wiht this justification-like thing, that we don't need to have the bottom align. - But when we print, it does matter. - So just wants us to make sure that this problem is important and hard. - Please think about this; let's go to next topic. - Kobayashi-sensei has written a 50page thesis on this available on the web, written in Japanese, Title is Something Something Vertical Something. <bobbytung> The Document Mr. Kobayashi mentioned is here (in japanese): http://www.cas-ub.com/project/publications/nihongokumihan.pdf myles: This was super awesome, thank you very much koji: I want to emphasize, from his statement, while line grid is important, in some cases there are more important things than aligning to the grid. koji: If those things happen, breaking rhythm is better. koji: In this discussion, people really want grid to be strong, while I feel grid is one of criteria, and when there is more important concern, need to shift. <dbaron> So one thing I wanted to understand was when he was talking about how breaking the rhythm was ok in one column but not when columns lined up -- and talked about having the thing that broke the rhythm top-aligned within the gap rather than centered -- I was wondering if anyone actually ever *wanted* it top-aligned, or that was just a deficiency of the software being used. dbaron: [example of image in the middle breaking the rhythm, and how image was top-aligned rather than centered] dbaron: In the multiple-column case, and wondering if idea of having that image top-aligned within the space dbaron: rather than centered within the space dbaron: was because of limitations in the software. dbaron: Was it preferable to have it centered, if that was possible? Kobayashi-sensei: Ideal is centered kobayashi-sensei: but some things are better top-aligned, e.g. side notes. [kobayashi-sensei draws some text with interruption as an image. Goal is to get spacing even on either side Draws a different example of vertical text, end-note of paragraph (after-paragraph note) end of chapter/section etc. This note is inserted at the end of the paragraph... has smaller text and line-spacing Spacing between lines and note is equal, but the space after the note is bigger There are cases where you center, and others where you start align For this situation, end notes, but not only also for pull-quotes (or block quotes?) In this case do the same as for end notes But some people like it centered ] myles: Is difference between two cases because vertical vs horizontal text, or difference is because image vs text. Kobayashi-sensei: Depends on content, not on writing mode. [Although this is a bit nuanced... according to Kobayashi-sensei, such end notes are more appropriate in vertical text, an footnotes are better for horizontal text. Also depends on if it's the kind of footnote you want people to read or if you want people to ignore them. ] inline step sizing ------------------ <murakami> http://www.cas-ub.com/project/publications/nihongokumihan.pdf fantasai: In print, the kihonhanmen size is chosen so that if it's all Japanese characters then everything fits perfectly fantasai: but on the web you don't choose the size -- the width is chosen by the width of the window fantasai: we have a request for step size of line box to be an integral multiple of the character count -- but then on the web we have extra space. What do we do with the extra space? [Kobayashi-sensei draws a book: text is single column; index page is double column different text sizes if you have exact line length on both, because font size etc. are all different; size of content area on page is different. You want index to be smaller than main content The extra space is distributed evenly around but sometimes you want to be slightly bigger on top this is independent of whether vertical or horizontal writing because humans have very good perception of equality in horizontal dimension, but there's an optical illusion, that things that look centered vertically aren't quite and this extra space is added to accommodate So you want centered, but ideally you want perceptual centering, which is not quite the same ] <astearns> the need to specify whether to center, top align or align baselines (for side notes) is why there are so many values for the box-snap property https://drafts.csswg.org/css-line-grid/#box-snap Kanbun ------ kanbun are Japanese version of Chinese writing, has little annotations around the characters It's for High School students (skk was explaining this) Kobayashi-sensei: There was this kind of material in JISX4051, but JLREQ considered it too advanced. skk: Challenge to create e-textbook using HTML/CSS/EPUB and this is becoming a requirement. Kobayashi-sensei: There's a lot of variations in this display, so creating a spec and implementations for this, it's extremely difficult. Florian: It's important Japanese cultural thing, but also horribly complicated. skk: Currently working around with abspos. fantasai: That's probably the right solution. koji: Kobayashi-sensei said, there were two types of Kanbun. First step is Japanese textbook with box of kanbun, but more advanced is whole book in kanbun, so need to page or scroll things. koji: Latter case is hard to do in abspos or svg Makoto: If you use a ?, then visual sequence is different from oral sequence. [Makoto points out the ordering of the example, it jumps around] dbaron: So you write it in Chinese grammar. ?: It's originally Chinese poetry. koji: Order is Chinese, and the check mark here, it means read the earlier one first. koji: The numbers say which needs to be read first in more complicated cases. Kobayashi-sensei: On the right side it's the readings annotations Kobayashi-sensei: Some of the annotations are how to read the Chinese character in Japanese, others are how to conjugate in Japanese Kobayashi-sensei: This character here has multiple possible Japanese readings Kobayashi-sensei: This mark says which one to use myles: This is really scary Kobayashi-sensei: Sometimes have one annotation, sometimes have more Kobayashi-sensei: Depending on expected level of the reader, will but varying levels of annotations Kobayashi-sensei: This is just one type of example xidorn: I've seen much more complicated examples, e.g. with a pronunciation for multi-character word Florian: Sometimes root of word is written with Chinese character, and conjugations are hanging off it. fantasai: You can get the layout into HTML+CSS using abspos. Not perfect, but probably best we can do, certainly for a long while. kobayashi-sensei: Best to just give up. fantasai: Use inline-grid for each one and its annotations :) [Makoto draws placement in example projected is incorrect ordering annotation should be left edge of gap between two chars pronunciation should be to the side,aligned to the bottom or to the top ] fantasai: I recommend marking it up as multi-level ruby and handling the display by styling each ruby as inline-grid. Kobayashi-sensei: If you have both reading and conjugation, they stick together and grow downward. Kobayashi-sensei: In a child's book, character can be really big, and you can have long annotation with wrapped annotation text. koji: Annotations here are explaining Chinese, so can be really long. ChrisL: Animation: follow the dot. Stretchy-brackets ----------------- Kanai: Here is a photograph of a Japanese cookbook. Kanai: Here there is a bracket symbol. Kanai: Explains how to make a custard... ingredients are bracketed together for this step. fantasai: Need stretchy brackets for math as well. dbaron: Looks a bit like a border image. <dbaron> it would be a little hard to do with a border-image <dbaron> to get the alignment points right fantasai: Do it with list items and the unicode box drawing characters, giving the first and last special characters. ?: line-spacing would break that koji: Is this particular to Japanese? bobbytung: No, also in Chinese. Florian: In English not quite the same, but have curly braces doing similar things. Kobayashi-sensei: This is not that common in Japanese either. Murakami-san: Inline block with big curly bracket? [warichu discussion] <dbaron> you can do it with border-image by setting roughly 1em border-image-width for the top and bottom sides, and leaving border-image-width as 1 on the left and right, and only having a border-width on the left myles: How important is this? Kanai: I'm a recipe book lover, so I always see this type of layout in cookbooks. Florian: Things that have lots of lists. ??: I never see this ??: It's not important ??: for this cookbook, it's a graphic support, designer can do. You can use image or list tag ??: issue of character alignment [discussion of using SVG] dbaron: border-image can do the right kind of stretching ??: Not a must, just nice to have. Murakami-san: Can already do with border-image. Florian: One difficulty is if you try to line up this corner with the font, because you need to guess the font metrics. koji: Best solution is custom paint. dbaron: Don't see how that's any better than border image. [skk wraps up]
Disposition of Comments tool instructions
Lea Verou   Sun, 1 Oct 2017 22:19:00 -0400

www-style > October 2017 > 0000.html

Received on Monday, 2 October 2017 02:19:23 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Hi all, This email is half a year overdue. Better late than never! In April, I made an app for easier creation and management of Dispositions of Comments, and many of you said I should write some instructions on how to use it. I finally wrote up some instructions and added them to the wiki here: https://wiki.csswg.org/tools/doc <https://wiki.csswg.org/tools/doc> Hope it helps someone else too! Let me know if you run into any issues and I'll do my best to fix them asap. Cheers, Lea Lea Verou ✿ http://lea.verou.me ✿ @leaverou
[CSSWG][css-sizing-3] Updated WD of Sizing, Last Call for Comments
fantasai   Sun, 4 Mar 2018 21:37:08 +0900

www-style > March 2018 > 0000.html

Received on Sunday, 4 March 2018 12:37:54 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-review-announce@w3.org.

The CSS WG has published an updated Working Draft of the CSS Intrinsic and Extrinsic Sizing Module Level 3: https://www.w3.org/TR/css-sizing-3/ This module extends the CSS sizing properties with keywords that represent content-based "intrinsic" sizes and context-based "extrinsic" sizes, allowing CSS to more easily describe boxes that fit their content or fit into a particular layout context. Significant changes are listed at: https://www.w3.org/TR/2018/WD-css-sizing-3-20180304/#changes and include * merging in the full definitions of all sizing properties from CSS2.1 (min/max?-width/height) and css-ui (box-sizing) https://www.w3.org/TR/css-sizing-3/#specifying-sizes * more thorough definition of replaced element intrinsic sizes https://www.w3.org/TR/css-sizing-3/#intrinsic and percentage sizing within indefinite containers https://www.w3.org/TR/css-sizing-3/#percentage-sizing * defining min-content and max-content to work on form controls * deferring the 'stretch' and 'fit-content' keywords to Level 4 (whose focus will be defining these keywords and 'contain') Open issues include: * Adding more illustrations (help wanted) https://github.com/w3c/csswg-drafts/issues/1938 * Working out how calc() values including percentages work on margins/padding/width/height/gaps when the container size depends on this child box’s size (input wanted) https://github.com/w3c/csswg-drafts/issues/2297 That is, currently when we are calculating the size of the container we treat a percentage size as zero. Then once the size of the container is established, we resolve the percentage against that size. What should happen if we have a size as calc(20% + 10px)? Do we ignore the 10px or honor it in some way? What about calc(10px - 20%)? See https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-sizing-3 for all open issues. We expect to transition to CR soon, so this draft effectively marks the beginning of a last call for comments period; we will be accepting comments at least through the end of March, and depending on the state of the draft, aim to transition to CR sometime in April. (We will of course process comments during CR as well, but would prefer to get them sooner rather than later.) (Note that the min-content and max-content keywords have already been officially cleared for shipping prior to CR by the CSSWG https://lists.w3.org/Archives/Public/www-style/2015Aug/0109.html since their syntax was stable and their behavior was tied to behavior exposed in existing CSS2.1 features.) Please review the draft, and send any comments to this mailing list, <www-style@w3.org>, prefixed with [css-sizing] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[css-grid-2] Updated WD of CSS Grid Level 2, Call for Comments on Subgrid
fantasai   Fri, 3 Aug 2018 18:09:49 -0700

www-style > August 2018 > 0000.html

Received on Saturday, 4 August 2018 01:10:20 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-review-announce@w3.org.

The CSS WG has published an updated Working Draft of the CSS Grid Layout Module Level 2: https://www.w3.org/TR/css-grid-2/ This draft contains the “subgrid” feature that was cut from the Level 1 CR last year, along with a few other minor things. At this point there are no further issues open against the subgrid feature, so we're asking for reviewers to conduct their final reviews against the feature. Significant changes are listed at: https://www.w3.org/TR/2018/WD-css-grid-2-20180804/#changes For the next update of this draft, we'll be incorporating the full text of the CSS Grid Level 1 specification along with the spec text for a few small feature requests (which depend on incorporating the L1 prose): - minmax() prioritizing max https://github.com/w3c/csswg-drafts/issues/1102 - auto-placement limited to named lines https://github.com/w3c/csswg-drafts/issues/796 - fr units as min inside minmax() https://github.com/w3c/csswg-drafts/issues/2611 At that point the L2 spec will be feature complete, and we'll start preparing it for CR. Please review the draft, and send any comments to this mailing list, <www-style@w3.org>, prefixed with [css-grid-2] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[CSSWG][css-text-3] Last Call for Comments on CSS Text Level 3
fantasai   Wed, 5 Dec 2018 18:25:09 -0800

www-style > December 2018 > 0000.html

Received on Thursday, 6 December 2018 02:25:56 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-review-announce@w3.org, www-international@w3.org, public-i18n-cjk@w3.org, public-i18n-bidi@w3.org, public-i18n-bidi@w3.org, public-i18n-indic@w3.org, public-i18n-arabic@w3.org, public-i18n-cjk@w3.org, public-i18n-hebrew@w3.org, public-i18n-mongolian@w3.org, public-i18n-jlreq@w3.org, public-i18n-sea@w3.org, public-i18n-tibetan@w3.org, public-i18n-ethiopic@w3.org, public-i18n-core@w3.org, public-i18n-core@w3.org.

The CSS WG has published an updated Working Draft of the CSS Text Module Level 3 and is issuing a last call for comments prior to requesting transition to CR. https://www.w3.org/TR/css-text-3/ This module contains various typesetting properties not related to font selection, such as alignment, line breaking, white space collapsing, text justification, and other forms of text-level spacing adjustments. This update completes the handling of all comments received during the 2013 Last Call period and up through today. A Disposition of Comments can be found at https://drafts.csswg.org/css-text-3/issues-lc-2013 The CSSWG requests review of the draft and the changes. If no further comments are received, we expect to transition the draft to Candidate Recommendation in two weeks, thus the deadline for comments or requests for extended time to review is Wednesday 19 December 9:00am Pacific Standard Time. Please review the draft, and send any comments to the CSSWG mailing list, <www-style@w3.org>, prefixed with [css-text-3] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues (Note that requests for new features are being deferred to Level 4. https://www.w3.org/TR/css-text-4/ This is just a request for review of the existing features in Level 3. Comments on Level 4 are of course also welcome; please file appropriately.) For the CSS WG, ~fantasai
Re: [CSSWG][css-text-3] Last Call for Comments on CSS Text Level 3
fantasai   Wed, 12 Dec 2018 14:02:30 -0800

www-style > December 2018 > 0000.html

Received on Wednesday, 12 December 2018 22:02:56 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-review-announce@w3.org, www-international@w3.org, public-i18n-cjk@w3.org, public-i18n-bidi@w3.org, public-i18n-bidi@w3.org, public-i18n-indic@w3.org, public-i18n-arabic@w3.org, public-i18n-cjk@w3.org, public-i18n-hebrew@w3.org, public-i18n-mongolian@w3.org, public-i18n-jlreq@w3.org, public-i18n-sea@w3.org, public-i18n-tibetan@w3.org, public-i18n-ethiopic@w3.org, public-i18n-core@w3.org, public-i18n-core@w3.org.

On 12/5/18 6:25 PM, fantasai wrote: > The CSS WG has published an updated Working Draft of the CSS Text Module Level 3 > and is issuing a last call for comments prior to requesting transition to CR. > >     https://www.w3.org/TR/css-text-3/ > > This module contains various typesetting properties not related to font > selection, such as alignment, line breaking, white space collapsing, > text justification, and other forms of text-level spacing adjustments. > > This update completes the handling of all comments received during the 2013 Last > Call period and up through today. A Disposition of Comments can be found at >   https://drafts.csswg.org/css-text-3/issues-lc-2013 > > The CSSWG requests review of the draft and the changes. If no further comments > are received, we expect to transition the draft to Candidate Recommendation > in two weeks, thus the deadline for comments or requests for extended time to > review is Wednesday 19 December 9:00am Pacific Standard Time. > > Please review the draft, and send any comments to the CSSWG mailing list, > <www-style@w3.org>, prefixed with [css-text-3] (as I did on this message) > or (preferably) file them in the GitHub repository at >   https://github.com/w3c/csswg-drafts/issues > > (Note that requests for new features are being deferred to Level 4. >   https://www.w3.org/TR/css-text-4/ > This is just a request for review of the existing features in Level 3. > Comments on Level 4 are of course also welcome; please file appropriately.) CSSWG has updated the draft on /TR with the following changes: * Some minor cleanup (largely editorial, some minor wording fixes that better clarify the interaction of properties) of the line-breaking section. See changesets in response to https://github.com/w3c/csswg-drafts/issues/2559 * Dropping percentage values of 'word-spacing', as we are likely to define them differently in Level 4 to satisfy some important use cases. See discussion in https://github.com/w3c/csswg-drafts/issues/2165 ~fantasai
[CSSWG][css-cascade-4] Return to WD / Last Call for Comments CSS Cascade L4
fantasai   Thu, 20 Aug 2020 16:12:26 -0700

www-style > August 2020 > 0000.html

Received on Thursday, 20 August 2020 23:12:42 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-review-announce@w3.org, public-review-announce@w3.org.

The CSS WG has returned the CSS Cascading and Inheritance Module Level 4 to Working Draft in order to: * Drop scoped styles, which were not implemented * Incorporate cascading and inheritance rules pertaining to Shadow DOM, which were (but were specced as a patch to Cascade rather than in Cascade) This is a Last Call for Comments; the CSSWG expects to return the module to CR soon. We are requesting comments, or alternately a request for extended time, by 20 September 2020. https://www.w3.org/TR/css-cascade-4/ Note: A corresponding updated CR of Level 3 to synchronize editorial fixes has also been published: https://www.w3.org/TR/css-cascade-3/ CSS Cascading and Inheritance describes how to collate style rules and assign values to all properties on all elements by way of cascading (choosing a winning declaration among many) and inheritance (propagating values from parent to child). For reference, the additions to Level 4 since Level 3 are listed here: https://www.w3.org/TR/css-cascade-4/#additions-l3 and consist of * Defining inheritance with shadows to operate on the flattened tree: https://www.w3.org/TR/css-cascade-4/#inheriting * Adding encapsulation contexts (such as shadows) to the cascade sort: https://www.w3.org/TR/css-cascade-4/#cascade-sort * Defining aliasing mechanisms: https://www.w3.org/TR/css-cascade-4/#aliasing * Adding global revert keyword: https://www.w3.org/TR/css-cascade-4/#default * Adding supports() conditional to @import: https://www.w3.org/TR/css-cascade-4/#at-import Please review the draft, and send any comments to the CSSWG mailing list,<www-style@w3.org>, prefixed with [css-cascade-4] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSSWG, ~fantasai
[CSSWG][css-sizing-3] Last Call for Comments on CSS Box Sizing Level 3
fantasai   Fri, 18 Dec 2020 12:51:25 -0800

www-style > December 2020 > 0000.html

Received on Friday, 18 December 2020 20:51:39 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org, public-review-announce@w3.org, public-review-announce@w3.org.

I also forgot to announce that on 23 October 2020, the CSS WG also published an updated Working Draft of the CSS Box Sizing Module Level 3: https://www.w3.org/TR/css-sizing-3/ We also published a minor update this week as CRD. These updates incorporate various fixes since the May 2019 Working Draft, and consist mostly of subtle adjustments to CSS's automatic sizing rules and miscellaneous editorial improvements. Significant changes since the previous May 2019 WD are listed at: https://www.w3.org/TR/2020/WD-css-sizing-3-20201218/#changes As there are hardly any issues left, we intend to transition this module to CR following completion of horizontal review. Consider this the Last Call for Comments! Please review the draft, and send any comments to this mailing list, <www-style@w3.org>, prefixed with [css-sizing-3] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai