W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Tue 2012-10-30 PM I: AltSS, Cascade, HTML5, Conditional Rules

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 23:03:34 -0800
Message-ID: <50A34246.4080303@inkedblade.net>
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
   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
   <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
   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
   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
   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
   <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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC