- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 03 Aug 2011 14:38:09 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
We worked through the items on the HTML5 LC review wiki page:
http://wiki.csswg.org/spec/reviews/html5
- 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.
http://lists.w3.org/Archives/Public/www-style/2008Feb/0130.html
http://lists.w3.org/Archives/Public/www-style/2011Apr/0163.html
- 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 ======
Present:
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
http://www.w3.org/TR/html5/links.html#pseudo-classes
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
issue.
<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?
<silence>
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
matter.
<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
stable
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?
http://dev.w3.org/html5/spec/Overview.html#replaced-elements
<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
sheets
<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
abandoned
<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>
http://dev.w3.org/html5/spec/Overview.html#the-iframe-element
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
<html>.
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
iframes.
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
serialization.
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