[CSSWG] Minutes and Resolutions TPAC 2011-10-30 Sunday Afternoon II: Style Attr, Selectors 4, Paginated Layout on Screen

Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

Style Attributes
----------------

   RESOLVED: Publish Style Attribute PR as soon as we have the
             implementation reports.

Selectors 4
-----------

   Daniel raised some concern that web designers are assuming everything
   in Selectors 4 will make it to CR, even though it's a very early stage
   draft and we don't know what will make it and what not. (The ability
   to select ancestors of elements is a particular area of concern since
   it is difficult to optimize for CSS selection.)

Paginated Layouts (GCPM)
------------------------

   Håkon presented a demo of a new paginated layout feature in Opera: it
   uses the 'overflow' properties to switch the UA into a paginated mode.
   The demo also included some new features for UI to link independent
   documents together into a single paged presentation.
   http://people.opera.com/howcome/2011/reader

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

http://www.w3.org/2011/10/30-css-irc#T20-04-28
http://www.w3.org/2011/10/31-css-irc
http://krijnhoetmer.nl/irc-logs/css/20111031#l-181

Style Attributes
----------------

   Arron: I didn't finish the implementation report yet, but I ran all the
          tests, all three of them.
   Arron: There needs to be three other tests, but all browsers pass except
          one case which is passed by 2
   dbaron: Is there a test for rejecting if there are braces around it?
   fantasai: yes.
   Arron: I'll try to finish off tonight.
   ACTION Arron: finish implementation report and tests
   <trackbot> Created ACTION-384
   ACTION fantasai: Publish test suite and implementation report on w3.org
   <trackbot> Created ACTION-385
   RESOLVED: Publish Style Attribute PR as soon as we have the impl reports.

Selectors 4
-----------

   glazou: Selectors L4 triggered a major reaction from web designer community
           because of subject selector and :matches()
   glazou: I can see that people don't really understand that presence of a
           feature in a WD doesn't mean it will be in an implementation
   glazou: I would like us to, at least for :matches() and subject selector,
           to clean up things asap
   glazou: If it's not going to be implemented by browser vendors because
           it doesn't fit into your strategy or impl architecture,
   glazou: then remove it from the spec quickly
   fantasai: :matches() is already implemented
   glazou: My fear is just that if we have something nice on paper that we
           find is too expensive to code, we should remove it quickly.
   fantasai: I think trying to cut off brainstorming work because people will
             interpret it wrong is bad.
   fantasai: also, the subject indicator may wind up in batch processors if
             not in browsers
   glazou: I'm not saying that, just that if our brainstorming finds something
           isn't implementable we should remove it as quickly as possible.
   fantasai: could be done in browsers, but will require careful optimization
             work
   fantasai: so may take awhile to find out
   arno: Do we know if anyone's currently planning to implement it?
   fantasai: There are tons of features - it's a very early stage draft - so
             we don't know that yet.
   glazou: I just didn't expect such a massively positive reaction to it as
           we got.
   szilles: So this falls into "careful what you promise, they might ask for it".
   glazou: So I'm specifically asking for devs to evaluate implementability
           as soon as possible on that feature.
   fantasai: What's in :matches() is absolutely implementable, since it's
             currently just syntactic sugar.
   fantasai: So we don't need feedback on that.
   fantasai: (At least, not immediately.)
   fantasai: It's the subject indicator that needs feedback.
   <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=418039 is the Mozilla
            bug on :subject
   tantek: What about :has()?
   <arno> indicator -> selector
   tantek: It's in jQuery, it's been adopted and liked.
   fantasai: I specifically went away from that because it's harder to implement.
   TabAtkins: Simple useful example: "label:has(:checked) + p"
   fantasai: You could use :matches() and the subject indicator to do the same.
   <Bert> (Tab's example doesn't work, does it? The p is not a sibling of the
           label, but a sibling of the labels's parent.)
   fantasai: "label:matches(? > :checked) + p"
   fantasai: [explains her example further]
   <dbaron> Clearly we should just use the ‽ operator or the ¡ or ¿ operator.
   <tantek> please no more symbols with strange meanings
   * tantek prefers to avoid CSS hieroglyphics
   * hober CSS IS *&@%#&*%^ AWESOME!
   <dbaron> ok, how about the 美 symbol :-)
   dbaron: The spec should say that using the subject indicator twice in a
           selector makes it invalid.
   tantek: I still think :has() is a superior syntax.  If you want to put
           restrictions on its functionality to match the subject indicator,
           fine, but use the better syntax.
   <dbaron> Let's avoid Dr. Streetmentioner's 1001 Tenses for Time Travelers
   fantasai: The interesting cases that :has() allows are precisely those
             that are much harder to implement.
   fantasai: Selectors *never* go down multiple branches when matching, right
             now.
   fantasai: Tab's example requires going down one branch and then going down
             another.
   Bert: The XPath syntax may be easier here, where it has an explicit
         ancestor selectors.
   dbaron: It's less hard to implement, than that it's hard to track dynamic
           changes.
   dbaron: For example, if you're selecting (in Tab's example), when the
           input is checked or not, you need to quickly figure out which
           elements need to be restyled, without redoing the entire page's
           layout.

GCPM
----

   howcome: I'd like to talk about what's new.
   howcome: Most of this is based on page floats, but also paged overflow.
   http://people.opera.com/howcome/2011/reader
   howcome: You can tell an element to overflow into pages.
   tantek: So it's a manual <marquee>?
   howcome: The other thing from GCPM is page floats.  These photos [in his
            slides] are floats spanning multiple columns.
   howcome: It works even better on a tablet.
   howcome: So basically we can create an e-reader.
   howcome: Paged layouts have been used forever in real life.  Also in lots
            of apps, like flipboard.
   howcome: [shows an example of paged wikipedia]
   howcome: It has a lot of nice properties.
   howcome: It avoids cut lines on the top and bottom of the screen when
            scrolling, frex.
   howcome: Some things were *designed* for paged presentations, like
            children's book.
   howcome: There's tons of gutenberg text, for example, that nobody will
            read because it's not paged.
   [shepazu objects]
   howcome: We've implemented it in Opera, and have an OM for it.
   howcome: [shows example of some presentation showing the current page, etc.]
   howcome: It's very simple.  The basic setup is with a 'paged' value for
            overflow, and the nav is done through an at-rule.
   plinss: How does it print?
   howcome: Quite well.  Opera doesn't print well, but if you pipe it to a
            good printing tool, it works well.
   plinss: When you're doing pagination of an element in the page, what
           happens when you print the whole page?  Where's the overflow?
   howcome: [shows the code example to set it up]
   fantasai: Since the overflow property on <html> is propagated to the
             viewport, you don't need the height:100% there.
   fantasai: Last time, we were thinking of having 'paged' be a value for
             overflow-style.
   howcome: Yes, 'overflow' is a shorthand.  The value can go anywhere,
            it doesn't matter right now.
   howcome: You can distinguish between pages being side-by-side, or below
            each other.
   tantek: In Japanese, you get pages right to left.
   fantasai: So you also have to check writing-mode, not just direction.
   howcome: Right.  If I say "paged-x", I take whichever logical direction
            is on the horizontal axis.
   shepazu: The scrollbar gives nice discoverability of how much content is
            left.  Is that still there?
   shepazu: Could there be a property that adds an indicator of the expected
            flow left?
   shepazu: "If there's another page, put an indicator there"
   plinss: There's an example in the spec with "paged-x-controls" for that,
           I guess.
   glazou: How does this interact with @page rules?
   howcome: Right now, our impl doesn't pay attention.  In the future, if
            you set the viewport to be overflow:scroll, it'll interact.
   howcome: If a line runs over the page (in the direction perpendicular
            from the main scrolling direction), it just gets cut (you can't
            see it in any way).
   howcome: Same as with multicol.
Scribe: fantasai
   Tab: These us multicol, so you have columns: 3 or whatever.
   Tab: If you're using columns, the overflow columns are to the side.
   fantasai: The columns are not overflowing the box. They're overflowing
             the page, and go to the next page. It just happens that the
             next page is physically placed to the side rather than below
             in this case.
   howcome: you see this in tablet apps, that do this repeatedly
   howcome: This is a very simple sketch.
   howcome shows page shift effects
   Brad: I think that should be up to the UA, so the UA can provide a
         consistent interface
   glazou: I don't see it as only for tablets. It's a wonderful spec to match
           the effects of switching slides in a powerpoint
   glazou: I think the primary usage of that will be slideshows, much more
           than tablet browsing
   molly: possibly, but I can see designers really loving it
   glazou: You can define navigation between 2 pages in same document, or
           between 2 documents.
   glazou: One issue we have with slideshows to dissolve one slide and show
           the next slide; we don't have the next slide yet when we load the
           document.
   molly: I want to make the case for this and not just slide shows.
   molly: Anyone read the NYT? Exactly what people are doing in NYT reader
   molly: it's being adopted a lot esp by older users who are not computer-savvy
   howcome: Met with NYT last  week, who are doing all this in JS. They are
            saying please save us from the JavaScript
   howcome: I'm really euphoric about this. I think it's the best thing that's
            happened in a long time.
   sylvaing: Since the Romans!
   howcome: It's so simple. No new properties, just new values on existing
            properties

   howcome: And then it's the at-page thing, which attaches to link elements
            in HTML
   howcome: here we tie thse relationships to the directions with an at-rule
   howcome shows example of @navigation using link-rel() notation
   howcome: If we want to compete with the apps here, I think we need to
            provide this form of interaction
   plinss: I think it's great on the root element
   plinss: When its on the child element, and you turn the page, what happens?
   howcome: Here it's on the child element
   plinss: Now hit print.
   howcome: I see your point.
   fantasai: I think you should print the page over again with the next child
             page until you run out of content in the child
   fantasai: Would solve lots of problems with fixed positioning
   fantasai: Although it would be weird if you had more than one paged child
   Tantek: Shouldn't print starting at what you're looking at, should print
           the entire document.
   Tantek: Wrt slideshows, it's horrible because then you don't get anchors
           to the slides
   tantek: If you do it with anchors tags, HTML5 history, fine. I've built that.
   Tantek: But you can't do dynamic paging with anchors
   plinss: It's the same problem of scrolling down to a page and wanting to
           point someone at that point.
   Tantek: yes, but the expectation is different: if I'm on a page, I expect
           to send a link to the page. If I'm in a scrolling document, I
           expect a link to that page to point at the top
   ...
   howcome: If I'm at the end of the document, it goes to the next one
   Doug: How do you know what's the next document?
   howcome: with HTML <link> tags
   howcome: you tie them to the navigation like this
   Doug: As you go to a new page with a fragment identifier, you update to
         that fragment identifier. That solves Tantek's problem.
   Tantek: Multiple navigation with a child?
   jdaggett: If you have 2 elements that are paginated
   Tantek: You'd have to scope per fragment the navigation rules if you have
           a paged child inside a paged document
   glazou: Just use a page break there. Define a page break after your sldies
   howcome: For slides that's fine. But for a newspaper article you don't
            want all the newspaper articles in one document.
   howcome explains url-doc(), which is a url relative to the document, not
           the style sheet.
   glazou: I think you should resurrect selectors on the right-hand side.
           This is too specific to HTML. Should be able to do this in any
           kind of markup
   glazou: Should be able to retrieve URLs from link anywhere in the prose.
   glazou: Smells like selector on right-hand side of property
   <TabAtkins> We have an existing function that can be used here - element()
   glazou: Looks like attr(link[rel=index], href)
   Doug: there's nothing HTML-specific about link relationships
   glazou: Next step that you are going to take Håkon is showing multiple
           pages into one single viewport
   glazou: To be able to select 5th page directly for example.
   glazou: So I suggest you think about this and put it in your proposal
   howcome: I'm going ot show you a book I printed in CSS.
   howcome: This is a replication of Digte by Henrik Ibsen from 1879. Each
            word on exactly the same page.
   Bert: If I swipe right to the next document, expect that going left
         brings me back. But that depends on the navigation styles in the
         other document
   Steve: I think it's a mistake to put the navigation in the style here.
          If you want to link together a bunch of document, should have
          some kind of manifest.
   plinss: this is outside the scope of CSS, but yes there's a use case
           for some kind of manifest that expresses these relationships
   fantasai: The links among documents can be expressed in HTML. The bit
             that's out-of-scope is mapping those to navigation gestures
   ...
   plinss: It should be next and previous
   howcome: That's already in the HTML, don't need the CSS.
   Steve: I think there's a difference between what happens in a document,
          which you specify with paged-x and paged-y, and what happens across
          documents, where I don't think it's the role of CSS to say. But
          getting to the end of a document is an event, and you could say what
          happens when you get to that event.
   glazou: I have a lot of comments on your document.
   howcome: Email probably works better if we want others to participate
            as well.
   howcome: So this is most of what's new in the GCPM. Maybe continue tomorrow?

Tantek: Request to add a photo of the folks that were here 7 years ago
Meeting closed.
<RRSAgent> http://www.w3.org/2011/10/31-css-minutes.html

Received on Monday, 28 November 2011 22:24:42 UTC