- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 23:03:34 -0800
- To: "www-style@w3.org" <www-style@w3.org>
CSS3 Cascade
------------
- RESOLVED: Drop alternate style sheet syntax from @import in css3-cascade.
- RESOLVED: Tab and fantasai to take over css3-cascade
- Plan going forward is:
1) remove alternate style sheets syntax
2) synchronize text with CSS 2.1 and make sure corrections
all copied over
3) editorial reorganization of spec to make sure it still
makes sense
4) Add cascading rules for scoped styles, the 'all' shorthand,
and the 'default' keyword
HTML5 Challenges
----------------
- RESOLVED: Add 'display: svg' and 'display: math' or something similar
at some point
- RESOLVED: Toggleable states is a cool idea and work on it at some
undetermined but not high priority.
See Tab's post for ideas and problems: http://www.xanthir.com/b4Kn0
- Discussed <iframe seamless>; CSS object negotiation algo needs an
update to handle it.
Conditional Rules
-----------------
- RESOLVED: Publish css3-conditional on Tuesday unless dbaron objects
within next few days
====== Full minutes below ======
Alternate style sheets
----------------------
Peter: This came out of discussion about alternate style sheets,
people asking what ever happened to them.
Peter: I accept there are reasons they haven't caught on.
Peter: I wanted to ask if there was something we could do to fix this.
fantasai: I think Alternate SS mechanism in HTML is sufficiently powerful.
fantasai: Problem is implementations aren't.
fantasai: Mozilla has UI to switch, but doesn't remember.
dbaron: I think it does remember now.
Peter: If I go to homepage of site and switch site, it should persist.
fantasai: That was all worked out as an implementation plan for Mozilla,
but never happened
Glenn: Intersects with OM, Anne spec'd some functionality.
dbaron: I thought that spec was sort of stable.
Tantek: I think this is just one instance with the problem with
prescriptive UI in specs.
Tantek: I think such things are doomed to fail.
Tantek: I think they're the form of a wishlist.
Håkon: But the spec didn't say what to do.
Tantek: The specs put in prescriptive UI, and that UI failed.
Tab: I find it unlikely we'll want to do anywhere near the same UI
other browsers.
Tantek: I think prescriptive UI is going to fail.
Peter: I don't think the problem is that the UI is overspecified.
Peter: I'm questioning if there isn't something missing in the
fundamental model to make this work.
Peter: We don't know where to preserve the choices for a given site.
fantasai: There are detailed proposals for that in the Mozilla bugs.
Tantek: I think that's an area where implementations need to innovate.
Tantek: We have the same problem with text zooming.
fantasai: I don't there's anything this working group needs to work
on for that.
fantasai: But there's one thing on this topic I'd like to get a
resolution on.
fantasai: There's a proposal for syntax for alternate style sheets
proposed in the cascade module for @import rules.
I'd like to drop that, at least until it's requested.
Peter: or at least at risk
fantasai: If we want Cascade module to be up-to-date, we shouldn't
take on functionality that nobody wants to work on.
RESOLVED: Drop alternate style sheet syntax from @import in css3-cascade.
<fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=altss
break-duration: calc(60 * 60s);
CSS3 Cascade
------------
Topic: Editorship of Cascade module
Tab: fantasai and I would like to take editorship of cascade from Håkon
Håkon: What needs to be done?
fantasai: 1) remove alternate style sheets syntax
fantasai: 2) synchronize text with CSS 2.1 and make sure corrections
all copied over
fantasai: 3) editorial reorganization of spec to make sure it still
makes sense
fantasai: 4) Add cascading rules for scoped styles, the 'all' shorthand,
and the 'default' keyword
Håkon: Are we doing scoped style?
Tab: Yes!
fantasai: The proposal for scoped styles, as I mentioned in the meeting
yesterday. Boris Zbarsky has a proposal for the cascading
part that we want to edit into the spec.
Håkon: I'm happy for you to edit; I still think we need to discuss that
feature.
Tab: I'd like to start doing those edits and then bringing it to discuss
in the group.
Bert: What is the 'all' shorthand?
Tab: We'd like to make 'all' a real property that's a shorthand for all
properties, that only accepts initial | inherit | default (once
we add default).
Tab: Reason for this is that authors sometimes want to shut off inheritance.
Tab: Authors don't want outer page's styles to leak into a widget.
Tab: Right now authors code very defensively.
Tab: The all property makes it very easy.
Bert: Shouldn't they mark it as a scope in the HTML?
Tab: Yes, in many cases, you want to do this properly.
Tab: But the shadow dom would like to have a non-magical mechanism to
reset inheritance.
Tab: When you don't need the full weight of shadow DOM, it can still
be useful to reset inheritance entirely.
Bert: Seems a bit frivolous.
Tab: It's a minor improvement that reduces a bit of magic in a few parts
of the platforms.
Arron: And it solves a problem that it's a pain to ...
Scribe: fantasai
dbaron: What about things that are in the UA style sheet where the UA
has an inherited property on the root, on the assumption that
we want that to be the default but let authors override it
TabAtkins: Discussed with bzbarsky of having 'default' roll back one
level of the cascade, resetting all author styles
dbaron: That assumes user prefs are expressed e.g. by changing the
definition of 'medium' rather than ways that put a style rule
in place on the root element
dbaron: font-size is ok, but other properties might not be
dbaron: suppose we didn't have a 'medium' font size keyword, handled
default by setting 'font-size: 20px' on the root
dbaron: so default does something magic with inheriting rules on
ancestors that are ua and user rules?
TabAtkins: [...]
[basically, this is an issue that needs to be considered]
RESOLVED: Tab and fantasai to take over css3-cascade
dbaron and glazou leave for the AC meeting
HTML5 Challenges (presented by Bert)
------------------------------------
Bert: Overall question is how much magic
Bert: we have some, for example: a link is a link, and we don't define that
Bert: CSS doesn't say when an element matches :link or :visited
Bert: So some magic we want to keep
Bert: But overall, think we should minimize magic
Bert: to be able to use as many features as possible in more environments
Bert: Here's a question -- do we need to say in CSS that you switch from
CSS to SVG model? To math model?
Bert: How does this interact with the box model
Bert: Do we define what it means
Bert: SVG and Math might have different answers
Bert: Do we want some way in CSS saying that you switch rendering models?
Bert: And in the case of math, do we want to define exactly how that works?
TabAtkins: I would like to see 'display: svg' and 'display: math'
TabAtkins: with SVG switching into a kind of abspos model
TabAtkins: And math for now just being handwavy as math, but work on it
more later
TabAtkins: Have had some discussions on integrating SVG and CSS models
better, think it's a good idea
Bert: Do we expect to support other types of rendering models?
TabAtkins: I think others should use existing layout model, or if using
something completely different, use this extension model
TabAtkins: Don't want to overly-generalize right now
TabAtkins: If in future have a 3rd language with its own display, give
it its own display value
plinss: Sounds reasonable. For consistency, do we go back and do <img>
and <iframe> ?
Bert, Tab: no that's replaced content b/c external file
arronei: once you're inside SVG element, CSS doesn't care anymore
TabAtkins: But would be better if integrate better
TabAtkins: e.g. not have to use <foreignObject> in SVG to include HTML bits
TabAtkins: But wrt CSS box model, would still behave as they do now
arronei: Do we then need inline-svg and svg?
TabAtkins: No, we need display-inside/display-outside :)
[side discussion on whether to split display]
Bert: An alternative is not to have a keyword per model, but just have
one keyword, 'foreign', and let it be determined by the namespace
hober: Single keyword doesn't tell you anything useful about what's inside
hober: or how to process it
<vhardy> For reference http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
TabAtkins: I would like to go and define an SVG layout model at some
point, add it at that point
TabAtkins: Maybe go ahead and say we'll define math value now?
fantasai: What if I set 'display: block' on an embedded <svg> element?
fantasai: Right now that just makes the SVG a block-level replaced element
fantasai: just like external SVG
fantasai: but if we go with your proposal, this will cause the SVG to break
vhardy: Might want to talk more with HTML guys of mixing svg and html
Bert: Next issue is math, do we define that layout model. There are useful
behaviors there, useful outside of math
Bert: Don't know how to get that done
TabAtkins suggests kidnapping David Carlisle
Bert: Have to work out details, but do people think math boxes in principle
is a good idea?
plinss: I think it's reasonable
plinss: I remember we looked at how to render math with existing CSS
Bert: There's a MathML profile for that. Doesn't quite look right, but
you can get quite far
ChrisL: If you redid that profile with Flexbox, would that help?
Bert: Maybe. Have to see what baselines are used
TabAtkins: Proposed resolution - Add 'display: svg' and 'display: math'
or something similar at some point
TabAtkins: Can solve the stylesheet overriding problem by having
display-inside: svg !important to UA stylesheet
ChrisL: display-inside/display-outside sets up a proper handoff mechanism
RESOLVED: Add 'display: svg' and 'display: math' or something similar
at some point
Bert: So, <details> element has an open attribute
Bert: So you can style differently the two different states
Bert: This is an example of a wider problem
Bert: Wider problem is, we should have a way to give every element two
states
<TabAtkins> I agree: http://www.xanthir.com/b4Kn0
Bert: Even a <section> or <div> should be able to be open/close
TabAtkins: I agree, and tried to write something up on this
fantasai: But you ran into a problem
TabAtkins: Yeah, ran into a fundamental problem.
TabAtkins: Circular dependencies
Bert: Did you look at the pseudo-class solution instead?
TabAtkins: This keys directly into :checked pseudo-class, except
generalizes so you can have more than 2 states
TabAtkins: Also does what HTML label element does, transferring checkedness
between elements. E.g. clicking on <summary> affects <details>
TabAtkins: But fundamental problem with this, whatever property turns on
ability to be checked
TabAtkins: If while it's there, you turn off that property, then it's a
problem
Bert: Do you actually need the property? Couldn't it just be implicit?
TabAtkins: Could imply checked / unchecked states for all elements, just
use pseudo-classes
TabAtkins: But doesn't let you do radio buttons
TabAtkins: which I've found to be super useful
TabAtkins: My suggestion is to go with this, but restrict the toggleable
property to not be set in pseudo-classes that read the toggled
state
Bert: You say you can have more than 2 states. I investigated that too,
but it seemed too complicated for authors
TabAtkins: Not sure it's necessary, though can come up with cases where
it would be useful
TabAtkins: But most cases I came up with were two states, but able to
make second state sticky so that clicking it doesn't toggle
the state away from the second state
divya: Maybe solve this through shadow dom?
TabAtkins: You'd be using shadow dom to put radio buttons into the shadow dom
TabAtkins: I think shadow dom brings in additional complexity that a tailored
CSS solution wouldn't
<ChrisL> if the labels are in the shadow dom then accessibility helpers
have more trouble discovering them
TabAtkins: It still doesn't give you the label functionality, necessary
even for simple case of <details>
Bert: So Tab thinks it's a good idea, anyone else?
fantasai: I think it's good problem to solve
divya asks for a prototype
TabAtkins asks for objections
hober: Object to what? Thinking about the problem?
Bert: Question is, do we put this in some working draft
sylvaing: Adding another module?
hober: I'm pretty sure this falls into the bottom half of our prioritization
list
Bert: So, a new working draft, it would be ok at some point
arronei: I don't think we need more than 2 states initially
TabAtkins: Does anyone think this is a bad idea, should not pursue?
hober: In generic case of multiple states, adding the complexity of
essentially of a state machine to all elements of all languages,
so maybe we should have reason to do this?
TabAtkins: I do this so often
arronei: It's such a common pattern on the Web, it's done everywhere
fantasai: I think this is a very common use case, to have collapsible
elements etc.
fantasai: Done with JS etc. all the time
fantasai: Think it's good to have a declarative solution
fantasai: whether purely CSS or integrating somehow with DOM
fantasai: Might be useful for DOM to be able to reflect the states,
or screen reader to react to the states
plinss: Bottom line is, no objections to further investigation
<divya> https://github.com/louisremi/Activable
<divya> is one solution to do a declarative markup way to do UI components
<ChrisL> http://www.w3.org/TR/scxml/
<divya> (which includes interactions such as what tab discussed)
<ChrisL> State Chart XML (SCXML): State Machine Notation for Control
Abstraction
<ChrisL> W3C Working Draft 16 February 2012
Bert: <details> has another issue -- when I tried to model it, problem
was that there's a part you want to show, and part you want to hide
Bert: want to hide most of it, except the summary
<TabAtkins> Easy: details:not([open]) > :not(summary:first-of-type)
{ display: none; }
Bert: Hmm, let me go back and see if that solves it.
leaverou: It doesn't work for direct text content of the <details>
RESOLVED: Toggleable states is a cool idea and work on it at some
undetermined but not high priority
Bert: List item is a replaced item whose height depends on width, but
not as an aspect ratio
Bert: e.g. <iframe seamless>
TabAtkins: I don't think there's anythign to do here
Bert: Need to update object negotiation rules for it
TabAtkins: [..]
fantasai: I agree with Tab that I don't think we need to add any features
to CSS for this
fantasai: But I also agree with Bert that we need to update the object
negotiation algorithm to handle this
ACTION TabAtkins and fantasai to update object negotiation algorithm
in css4-images to handle <iframe seamless>
<trackbot> Created ACTION-522
Bert: So the style sheet author doesn't need to set anything?
fantasai: No, the object itself returns different information in this case
fantasai explains why this is the case
[you always try to get the best intrinsic size that you can get, and in
the case of non-seamless iframes this is nothing, whereas seamless
iframes can return a sizing function]
Bert: Ok, I guess it's good enough
Conditional Rules
-----------------
TabAtkins: Only one remaining issue on css3-conditional
TabAtkins: Decided to loosen parsing things, treating unknown constructs
as false
TabAtkins: rather than making rule invalid
TabAtkins: The only real change is...
TabAtkins: This bit, supports_condition, now uses 'any' token from grammar
TabAtkins: As long as you match pretty much anything at all in there
TabAtkins: If you don't see one of the grammar constructs listed, it
drops out as false
TabAtkins: Should be all we need.
TabAtkins: As far as I can tell, it's right
TabAtkins: It's just details to tweak to make it clearer
TabAtkins: So, because of this change, we should now have all issues
resolved, and should be able to resolve to go to LC
TabAtkins: Anyone object to publish LC?
fantasai: I'd like dbaron to have a chance to review this, but otherwise
looks good
RESOLVED: Publish css3-conditional on Tuesday unless dbaron objects
within next few days
Bert: You're limiting what you can do in the future, but why make things
false when you don't understand them?
TabAtkins: This is to make it easier to extend in the future
TabAtkins: We don't want the presence of new things to wipe out the
entire @supports rule in older UAs
TabAtkins explains why this makes sense
plinss: but sometimes will get wrong answer
TabAtkins: Will sometimes fail, but gives better forward-compat overall
Received on Wednesday, 14 November 2012 07:05:53 UTC