RE: Floats, books and regions

± In your example you use regions to create a table of contents.
± 
± Using CSS to create a table of contents seems to me to be using CSS on the
± wrong side of the barrier between content and presentation; a table of
± contents is a part of the content presented to the user and should be in the
± content in the markup, not merely something brought into existence by the
± presentation.

I guess one could see it that way. One could also see it another way, where the table of contents is just "another view" over the content.

For instance, click on any heading here to trigger the "table of contents" layout: http://fremycompany.com/tomographie/articles/2011-03-20-16-04-13.php (not sure why videos do show up in this mode, but anyway) then click on any title to scroll to it and return in normal layout. Clearly, there's only one content here, and the table of contents is just another way to display this information. The auto-generated table of contents shown in the demo follows this spirit, but allows both the table of contents and the content to coexist.

 
± For a start, in HTML, one would normally expect a table of contents to have
± links in it (to the sections).  These links should be links in the markup; they
± should behave like links to browsers, accessibility tools, browser extensions
± that examine links, search engines, etc.

If you look up closely my demo, you'll see I did think about it. Every <hX> tag has a <a> link to it that can be used for people to discover heading bookmarks and can be used in the table of contents to make the heading zone clickable (with position: absolute; top/left/right/bottom: 0px). Another option would be, as in the case of the tomography-website, to make sure the link encapsulates the text of the heading, which would be more semantic (the paragraph box can be generated by using ::after on the link, then).



± Second, many APIs on the Web, for example, relating to selection, scrolling a
± piece of content into view, etc., are designed around the assumption that
± the content is part of the content.  In your regions example, what does it
± mean to select text in the heading, or that crosses a heading?  

If you refer to the fact I cannot select two subsequent headings in the table of contents without selecting all the paragraphs between them in the real content, I'm tempted to reply this is a DOM Selection problem. We need to be able to make multiple-range selections on the web, and we can't. We shouldn't blame regions for this, either.

I can select columns in a table in Word, Pages and basically-whatever-editor out there. I can't on the web because <td> are arranged by rows and we can't have multiple selection ranges. Here's the problem, look no further.


± What does it
± mean to scroll one of those h1 elements into view programmatically?

The same it means to scroll to an element that span over multiple columns: one box is the main box and takes the purpose of this kind of operations. As soon as an element generate multiple boxes, there's some potential confusion, but it's possible in this case to resolve this in a fairly consistent and intuitive way. In this case, the "in-content" instance is the one that gets scrolled into view because this is the first copy. The author can thus control which box is considered the "main" representation of the element just by adjusting the order in the "flow-into" declaration so that the first one (or last one) is the one he consider the main representation.



± I think one characteristic of building software systems is that we make
± simplifying assumptions / limitations some of the time so that we can build
± systems with a level of complexity that we can understand.  I think many
± APIs on the Web are built around the assumption that content is part of the
± content, and adding content in the presentation layer is the wrong solution.

This is an argument I can hear. Basically, this is the only argument I've ever read about Regions that makes sense to me. Regions is a feature that exposes many other stuff that weren't so exposed in the past and it is very possible exposing this stuff will reveal a lot of bugs to fixes because of broken assumptions. There's also the burden it adds to people learning about the DOM because an element can now have multiple parent elements for layout purposes while only one parent for DOM and inheritance purposes. That's arguably some weird asymmetry.

That being said, I'm not sure it's a bad thing. Trident and Blink/Webkit were both able to manage to get Regions working. Yes there are still issues here and there, but it looks to me this feature was implemented in a rather stable way much faster than I would have thought it would have been possible if I was responsible of the project. Maybe it's just because it's actually easier than one could think.

I would maybe recommend Adobe people to make a report on what the implementation of regions took in Blink/Webkit and explain the challenges they faced and how they solved them. Their technical expertise may help make a better estimation of the time and complexity involved. This could also be educational to people hitting region code they don't understand in the future in Blink/Webkit.

Also, there will be some work required to implement the new css-break specification which has been much overhauled recently (thanks guys, btw!) and such work will likely hit some of the issues regions would have exposed anyway.

Received on Monday, 27 January 2014 10:09:14 UTC