W3C home > Mailing lists > Public > www-style@w3.org > August 2011

[CSSWG] Minutes and Resolutions 2011-08-03

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 03 Aug 2011 14:38:09 -0700
Message-ID: <4E39BFC1.60506@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   We worked through the items on the HTML5 LC review wiki page:

   - RESOLVED: Send comment that pseudo-selectors section should have normative
               references to Selectors 3 / CSS3 UI
   - RESOLVED: HTML5 should update to and reference Selectors 4 for :ltr and :rtl,
               See also http://www.w3.org/Bugs/Public/show_bug.cgi?id=13346
   - ACTION plinss: Write up selectors coordination issue wrt ::cue et al.
   - RESOLVED: issue about lack of disabled attribute in <link> is not a
               CSSWG comment
   - ACTION plinss: Write comment on referencing CSSWG editors' drafts
   - RESOLVED: No CSSWG comment on case-insensitive attribute values
   - RESOLVED: No comment on video { object-fit: contain; }
   - RESOLVED: font-size: xxx-large is not a CSSWG comment to HTML
   - RESOLVED: Bert sends attribute value normalization comment on his own; not
               a CSSWG comment
   - RESOLVED: Bert sends white space parsing issue on his own
   - RESOLVED: No comment on <details> markup
   - CSSWG needs to do some work to make <details> usable, see e.g.
   - RESOLVED: <iframe seamless> has some problems that need fixing
   - ACTION Tab: Write up a comment on <iframe seamless>
   - RESOLVED: Adopt Bert's comment on normativeness of Chapter 10 as
               CSSWG comment.
   - RESOLVED: No CSSWG comment on HTML namespaces

====== Full minutes below ======

   Tab Atkins (via IRC)
   David Baron
   Kimberly Blessing
   Elika Etemad
   Sylvain Galineau
   Peter Linss
   Edward O'Connor
   David Singer
   Anne van Kesteren (via IRC)

<RRSAgent> logging to http://www.w3.org/2011/08/03-css-irc
Scribe: fantasai

HTML5 LC Comments

   <plinss> http://wiki.csswg.org/spec/reviews/html5
   plinss: The one topic today is HTML5 LC comments
   fantasai: the ones at the top are just a list of issues, need a proper
             writeup to be a comment
   plinss: Should we go over them to see if we agree?
   fantasai: Yes, but we need to assign action items for writeups.
   <dsinger> Do we need to separate CSS-related comments from other more
             general comments?

   plinss: First item, UI selectors and split between CSS3 UI and HTML5
   fantasai: The main problem I see in this section is that there's no
             normative reference to Selectors /CSS3UI that define the selectors
   <TabAtkins> Note: there is no split.  The only difference is in the
               direction selectors, which is between Selectors 4 and HTML.
   <fantaai> TabAtkins, the split is that our specs define the selectors and
             HTML5 defines when they apply
   <Ms2ger> There is a normative reference to Selectors and CSS3-UI, btw
   <fantasai> Ms2ger: I don't see it, where?
   <anne> fantasai, http://www.w3.org/Bugs/Public/show_bug.cgi?id=13613 (on not having a normative reference)
   <Ms2ger> They are in the references section at least
   <anne> Ms2ger, yes for the rendering section
   <anne> Ms2ger, not for the pseudo-class section
   <Ms2ger> Mm

   <sylvaing> did we log daniel's comment on 10.4.2: "This section is intended
              to be moved to its own CSS module once an editor is found to
              run with it."
   <fantasai> I think that fell under the coordination / lack of communication
   <sylvaing> it's more than that; this note says the section is a CSS feature
   <sylvaing> but certainly needs coordination work
   <anne> sylvaing, I emailed www-style on that
   <anne> sylvaing, only Tab replied thus far
   <sylvaing> anne, yes you did. I thought it should be on the wiki as one of
              the issues we might comment on.
   <anne> sylvaing, it is the third bullet point no?

   fantasai: I think some of Bert's comments should be sent as personal
             comments, not as WG comments
   dbaron: In general, I think comments shouldn't be sent as group comments
           unless they really affect the interaction of the specs
   fantasai: A lot of these do
   dbaron: Yes
   plinss: So let's go over the issues and decide what to do with that

   fantasai: For UI selectors issue, I think the only problem is the lack of
             normative reference. Looks like anne filed that
   fantasai: But that should be considered a WG comment
   fantasai: Anyone else have comments on UI selectors issue?
   plinss: So do we want to send that as a WG comment?
   fantasai: How do we do that?
   ACTION fantasai: Write a paragraph linking to this bug so plinss can send it
   <trackbot> Created ACTION-359
   RESOLVED: Send comment that pseudo-selectors section should have normative
             references to Selectors 3 / CSS3 UI
   <anne> I don't see any reason to send it as WG comment if the issue is
          already filed
   <fantasai> anne, it's still an issue raised by the WG
   <anne> "The CSS WG endorses this comment"? seems fairly lame to me
   <anne> it's an issue raised by you and I filed it
   <sylvaing> anne, and i don't see any reason to not be complete. If it's just
              a matter of linking to a filed issue the cost seems pretty low.
   <anne> sylvaing, you mean filing an issue on HTML?
   <anne> sylvaing, not sure what that would say

   plinss: :ltr, :rtl ?
   <anne> already filed
   plinss: Should have a draft of Selectors 4 for them to reference soon
   fantasai: So do we put this in the issue list? What do we put?
   fantasai: That it needs updating and a reference to Selectors 4?
   plinss: Yes
   RESOLVED: HTML5 should update to and reference Selectors 4 for :ltr and :rtl,
             See also http://www.w3.org/Bugs/Public/show_bug.cgi?id=13346

   plinss: ::cue pseudo-element, :past/:future pseudo-classes
   fantasai: I added :past and :future to Selectors 4 yesterday
   plinss: We do have the general issue of HTML going off and defining
           pseudo-classes and pseudo-elements without talking to us about it.
           We need a general statement that they shouldn't do that.
   <TabAtkins> ::cue is potentially interesting to look into.  It's actually
               a generic way to poke selectors into embedded documents.
   <TabAtkins> Though currently limited to WebVTT, which doesn't have a way
               of embedding CSS itself.
   fantasai: Don't have a draft for ::cue, not intending to add it as we're
             defining pseudo-elements in their own related modules
   <anne> it's not selectors in embedded documents...
   plinss: I think we can file it as a general issue that this isn't defined
           in CSS, there's been no communication to the CSSWG about it, it
           needs to be defined somewhere in CSS but we need to work together
           on it at some point in the future.
   <anne> well it is, but not Selectors selectors
   fantasai: So you want to write that one up?
   plinss: yep
    ACTION plinss: Write up selectors coordination issue wrt ::cue et al.

   <anne> plinss, I communicated it to the CSS WG
   <sylvaing> anne, you were saying we shouldn't need to mention it if the
              issue has been filed. I'm saying if it has been we should link
              to it. If it hasn't, we should highlight it as an outstanding
              issue since it is one. that's all.
   <anne> sylvaing, it points to an email that asks the CSS WG to work on this
   <anne> sylvaing, it has done since that page existed more or less

   fantasai: disabled attribute, should it be WG comment or Daniel comment?
   plinss: Probably Daniel comment.
   plinss: I'll ping him about it
   RESOLVED: comment about lack of disabled attribute in <link> is not a
             CSSWG comment

   fantasai: normative references to CSS editors' drafts?
   fantasai: Should be a WG comment
   <Ms2ger> Should be fine
   plinss: Just say they shouldn't be doing it
   <anne> agreed with Ms2ger
   plinss: We discussed a little at the F2F
   plinss: Some said it's just their problem wrt not being able to advance
   <anne> I wouldn't want HTML to reference a WD of CSSOM at this point
   * Ms2ger wonders if the CSSWG has any power over the HTMLWG so it can say
            what the latter can and cannot do
   <sylvaing> anne, right. it's an issue so it should be listed. moving on...:)
   fantasai: CSSWG handles editors' drafts differently from HTMLWG, ours are
             not the official WG-endorsed copy
   hober: Should we maybe expedite some updates to WD?
   <anne> no not the CSSWG
   <anne> some people in the CSSWG
   <anne> and some treat them pretty much the same
   plinss: Yeah. We're happy to publish updates as soon as the editor says
           they have something to update
   hober: I think that would be useful to communicate in the comments
   <anne> this whole "lets talk as a WG" makes little sense to me
   plinss: I'll write that one up
   plinss: Should I provide a list?
   fantasai: could do, list them and the URLs they should be updated to
   ACTION plinss: Write comment on referencing CSSWG editors' drafts

   plinss: case-insensitive attribute values
   fantasai: Is this just values? Bert raised an issue about attribute names..
   plinss: Bert's comment is about elements and attributes
   <anne> bert is wrong
   plinss: Could combine
   fantasai: Well, they're different. Adding a new syntax to do case-insensitive
             value matching is one thing
   fantasai: Having element selectors match case-sensitively in XML is another
   <anne> element names and attribute names in XML are matched case-sensitively
          and that should never change
   <anne> there's no use case for that anyway
   <anne> the only use case is for attribute values
   fantasai: I don't know where Bert's getting this idea then
   fantasai: But if it's not correct, then we shouldn't send that as a comment.
   <anne>  /* case-insensitive */ in HTML refers to this definition
   <anne> "Similarly, for the purpose of the rules marked "case-insensitive",
          user agents are expected to use ASCII case-insensitive matching of
          attribute values rather than case-sensitive matching, even for
          attributes in XHTML documents."
   fantasai: I don't see a problem with that.
   fantasai: So I don't think we need to send this as a comment.
   plinss: Bert's comment or?
   fantasai: Well, Bert's comment is wrong, so we shouldn't send it
   <anne> I already filed a bug on replacing that construct with the new i-flag
   fantasai: For the other issue, I don't think how HTML defines it is a
             problem. And they can use the new Selector 4 syntax once that's
   plinss: No comment on this one?
   fantasai: right
   RESOLVED: No CSSWG comment on case-insensitive attribute values

   plinss: Next, rendering depends on video { object-fit: contain; }
   fantasai: What does that mean?
   <TabAtkins> The rendering rules of video were previous explicitly described.
               They can instead be described succinctly by that UA style.
   fantasai: It says the following rules apply, and lists
             video { object-fit: contain; }
   fantasai: I don't see a problem with that
   * Ms2ger neither
   fantasai: Does anyone else see an issue?
   Nobody sees an issue
   plinss: Who added the issue?
   plinss: Anne
   RESOLVED: No comment on video { object-fit: contain; }
   <anne> oh, I noted it since we marked it at risk in css3-image

   plinss: xxx-large issue?
   fantasai: Seems like a comment they should make on our spec, not a comment
             we should make on theirs
   RESOLVED: font-size: xxx-large is not a CSSWG comment to HTML
   <TabAtkins> Yeah, it's solely a convenience in the stylesheet, like the
               "X" selector used in describing the styling of headings.
   <anne> the X selector can be replaced by :matches I think

   plinss: Attribute value normalization
   fantasai: I think this issue is out of scope for us
   hober: Wouldn't it affect selector matching?
   <anne> it would
   fantasai: And a lot of other things besides, but how they parse their
             document isn't in our scope imo
   * Ms2ger agrees with fantasai
   plinss: It's still a valid comment
   fantasai: Yeah, but Bert should send it on his own. It's not a coordination
             issue between us and them
   RESOLVED: Bert sends attribute value normalization comment on his own; not
             a CSSWG comment

   plinss: Alternate style sheets?
   fantasai: Seems like a fair comment.
   <Ms2ger> It doesn't seem like something that should go in HTML
   fantasai: CSSOM should explain how it interacts with scripting, but the
             definition of which style sheets apply otherwise should be defined
             in HTML.
   hober: So comment should be they define it themselves?
   fantasai: Theoretically you could have non-CSS style sheets, that's allowed
             by HTML, so it's not a CSS thing.
   hober: This half-reads as a comment on CSSOM spec, not sure what that has
          to do with HTML spec
   plinss: http://dev.w3.org/html5/spec/Overview.html#styling
   fantasai: This seems like a "what's the right dividing line between CSSOM
              and HTML" issue
   fantasai: And I'm not sure the line is drawn in the right place
   plinss: Who wants to write this up in a better way?
   fantasai: I guess I can write it up? I don't know anything about the OM,
             so I'm not sure that's a good idea...
   hober: I'm not sure there's an issue, but might be artifact of how big and
          unweildy the HTML5 spec is
   * Ms2ger thinks the line is drawn correctly
   hober: It does define how style sheet is loaded
   hober: It defers to CSSOM the scripting of enabling and disabling the style
   <Ms2ger> If alternate style sheets aren't defined, that seems like a bug
            for the CSSWG
   hober: And that should live in the OM
   fantasai: You don't need scripting support to support alternate style sheets
   hober: There's two bits of that, is there some kind of UI exposed to the
          user -- that's out-of-scope for HTML spec
   hober: And there's the scripting interface, which should live in CSSOM
   fantasai: HTML4 had a section on alternate style sheets. Not very well
             written, but it described which style sheets were enabled by
             default, which style sheets were grouped together as a style set,
             and which style sheets were enabled or disabled when you switched
             style sets
   fantasai: Interaction with disabled attribute just wasn't part of that
   hober: There's not a good part of W3C to write that down, so not clear
          where it should go
   hober: Not specific to HTML that there's a concept of alternate style sheets
   <Ms2ger> It looks like alternative style sheets in HTML are already defined
            in css3-cascade without a ref to HTML4
   <Ms2ger> There's nothing left to define in HTML besides the OM
   hober: It might be reasonable for us to narrowly scope the comment, say
          yes the scripting part of this should be in CSSOM, but the other
          part shouldn't, and HTML should either write down how alternate
          style sheets work, how the disabled attribute interacts with that ...
   hober: Not clear to me CSSWG specifically should do that
   hober: As you said, could have other style languages
   hober: Might be reasonable for Style Activity to handle that somewhere
   <Ms2ger> hober, The CSSWG already does that
   hober: I'm agreeing there's a missing piece of prose. Not sure where it
          should go. Not specific to HTML, it's a part of the web platform.
          Other languages could have notion of alternate style sheets as well
   fantasai: There's only two places that have this notion: HTML and the
             xml-stylesheet PI
   <fantasai> http://www.w3.org/TR/xml-stylesheet/
   plinss: So what do want to say to HTML5?
   fantasai: To make sure this is defined, either by writing the spec or
             finding someone else to write the spec
   <Ms2ger> fantasai, Also @import according to css3-cascade
   <fantasai> Ms2ger, any draft that's older than 2007 should be considered
   <Ms2ger> Replace it, then

   plinss: White space where HTML4 ignored it
   hober: Not really a CSS issue
   RESOLVED: Bert sends that one on his own

   plinss: details element
   <Ms2ger> The body element proposed there has been rejected several times
            already, fwiw
   fantasai: We can't handle this in CSS yet, but I don't see a problem
             with the spec
   hober: Tab was looking at handling the disclosure triangle via ::marker
   plinss: Is a case where we might need extra markup
   hober: Nothing's stopping authors from wrapping contents in a DIV
   fantasai: The bit I'm not seeing here is the behavior.
   fantasai: We can show a disclosure triangle, but that doesn't give it the
             ability to change the open and close states
   <Ms2ger> That's out-of-scope for CSS, I guess
   <TabAtkins> That part is done via the element's own magic.
   <TabAtkins> That is, it's a part of <summary>'s activation behavior.
   <fantasai> TabAtkins, is that defined somewhere?
   <hober> "The user agent should allow the user to request that the additional
           information be shown or hidden. To honor a request for the details
           to be shown, the user agent must set the open attribute on the
           element to the value open. To honor a request for the information
           to be hidden, the user agent must remove the open attribute from
           the element."
   fantasai: We definitely need to add something about collapsing stuff, though.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Feb/0130.html
   fantasai: Do we have selectors for the open and close states?
   <TabAtkins> Yes, details[open]
   <TabAtkins> Or details:not([open])
   <fantasai> TabAtkins: that selects on getAttributeSOMETHINGOROTHER
   <TabAtkins> (The content attribute reflects the state of the element.)
   <fantasai> oh, ok
   <fantasai> TabAtkins, I think it'd be handy to have an example of that
              in the spec
   <TabAtkins> fantasai: Okay, I can file a bug.
   <fantasai> like, it could just be [open] { background: pink; } makes it
              pink when it's open
   <TabAtkins> Done: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13615

   plinss: But we still don't have a way of collapsing the contents that
           doesn't have an element around it
   fantasai: I think we can add something that works similar to 'visibility'
             or 'speakability' from CSS3 Speech
   fantasai: I don't have an issue to file, anyone else?
   RESOLVED: No comment on <details>

   plinss: <iframe seamless>
   fantasai: So what does seamless do ...
   fantasai: So this is *not* about replaced elements
   <TabAtkins> seamless makes the iframe act more-or-less like its contents
               were just embedded into the outer document.
   fantasai: This is way more sophisticated than adjusting the height of a
             replaced element
   <TabAtkins> For sizing, at least.  Also, selectors cross through the boundary.
   fantasai: I'm not sure if I have a comment on this... does anybody else?
   fantasai: The only thing I can think is that we need to define handling a
             document tree that's composed of multiple documents.
   fantasai: Ths is effectively an include
   <TabAtkins> I don't think we need to say anything, really.  The tree is
               still well-formed.
   plinss: There's bits about setting the intrinsic size of the <iframe>
           that confuse me
   fantasai: yeah, that doesn't make sense ..
   <fantasai> TabAtkins, defining cascading and inheritance should be our
              responsibility, ideally ...
   plinss: This whole section of HTML frightens and confuses me
   <TabAtkins> Actually, my statement's not quite true.  Selectors don't match
               across the document boundary.  However, stylesheets from the
               outer document are applied to the inner document as well.
               Then, inheritance applies between the <iframe> and the inner
   hober: Yes. But seamless <iframe> is still treated as a replaced element.
   fantasai: I'm not sure...
   hober: It's still just a rectangle
   fantasai: What if you make it a circle with exclusions or something?
   plinss: Is it just a replaced element where the style bleeds through and
           you don't get a border? Or is it something different?
   <TabAtkins> For sizing, it *should* be saying that the width is computed
               as if it were a non-replaced element (without any contents).
               The height is set to the bounding box of the inner document.
   hober: I think it's just a replaced element with the listed exceptions
   fantasai: What happens if you set 'width: min-content' on it?
   <TabAtkins> Presumably it's still sized as if it has no content, and
               thus would shrink to zero?
   <TabAtkins> Good question.
   fantasai: yeah, I think this has issues
   <TabAtkins> Okay, so we should file some stuff on the sizing of seamless
   fantasai: I don't think this is quite thought through.
   <oyvind> "height is set to the bounding box of the inner document" -
             sounds circular reference-y
   dbaron: It's just including the box tree
   fantasai: Is it that or treating as a replaced element?
   fantasai: It says set the intrinsic height to this and intrinsic width to
             that. That gives it an intrinsic ratio. Do you scale ts height
             when you change the width?
   dbaron: ... ok, I guess it's not that clear.
   plinss: Bottom line, what do we say to HTML?
   <TabAtkins> fantasai: Going strictly by the definition, you'd change the
               intrinsic width when the page's width changed.  ^_^
   fantasai: "You're messing withe the CSS box model in ways you do not seem
              to understand. Maybe you should talk to us and work on a spec
              jointly." :)
   <TabAtkins> I think we should file a bug on @seamless to fix the way its
               sizing is defined.
   <dbaron> I don't think it's as bad as fantasai says, but I do think it
            needs to be better defined.
   plinss: So can someone please take an action to write up a coherent
           comment here?
   <TabAtkins> I can do that.
   ACTION Tab: Write up a comment on seamless
   <trackbot> Created ACTION-360
   <oyvind> (my previous comment was in response to what Tab said, I see now
            that the spec sets initial containing block height to 0)

   plinss: Scoped style sheets
   plinss: comment says they're not needed?
   dbaron: I think we do need them. And we need to define them.
   plinss: I'll agree with that.
   <TabAtkins> Me too.
   fantasai: I have to go, but my comments on the rest are that:
   fantasai: If chapter 10 is the rendering section, we should adopt Bert's
             comment on that.
   fantasai: Anne said the next one is wrong, so no issue
   fantasai: namespaces issue is out-of-scope for us imo, and I don't see it
             as an issue.
   fantasai: you can discuss scoped without me, I will not be able to minute.
   dbaron: Anything to discuss?
   fantasai: What the comment should say?

Scribe: hober
   <TabAtkins> I think we should pull scoped-ness into CSS directly at some
               point, but I also think that <style scoped> works just fine as is.
   dbaron: I'm not convinced we need to make a comment here
   plinss: drop this comment then?
   hober: sure

   plinss: accept comment on chapter 10?
   sylvaing: agreed re: chapter 10
   RESOLVED: Adopt Bert's comment on normativeness of Chapter 10 as CSSWG comment.

   plinss: Pseudo-namespaces
   plinss: fantasai said she thought this was out of scope
   <TabAtkins> HTML defines namespaces properly.  All HTML elements are in a
               namespace, regardless of whether you use the HTML or XHTML
   plinss: i think it's fine for an html document to have a namespace
   <TabAtkins> And it's *definitely* not a CSS issue.
   dbaron: the way text/html parsing works, dom elements get the xhtml, svg,
           or mathml namespaces
   plinss: drop this comment
   RESOLVED: No CSSWG comment on HTML namespaces
Received on Wednesday, 3 August 2011 21:38:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:48 UTC