W3C home > Mailing lists > Public > www-style@w3.org > April 2011

[css3-regions] elements vs. selectors

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sun, 3 Apr 2011 10:06:21 +0000
To: www-style list <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928411F14ACD@TK5EX14MBXC213.redmond.corp.microsoft.com>
I think there should be a dedicated HTML element to represent a "region".

I know it sounds like I am out of my mind. And it is on the opposite end of spectrum from "slots" (as I understand them), but let me explain.

We are going to bring to the web another concept of established typographic tradition - linked text boxes. It's a set of containers, possibly of irregular shapes, that text of a story can flow through, and you can follow the story by moving your eyes from one box to another, just like flipping pages.

So we need a definition for something like this...... 

A) Object to represent a "story" (not a common technical term, but I like to use it to refer to represent some amount of text that has a beginning, an end and a linear progression in between). 

-- It has content (which might be some text that it literally contains, 
   or perhaps it could be a link to a file). 
-- It has no rendering but it can provide content stream for containers 
   that are willing to render it.
-- It has a way to be identified (for example a name). 
-- I may need OM to read and/or modify the content

B) Object to represent one of the linked boxes that display the content of a story. 

-- It needs a way to refer to the story (story object that is). 
-- Given a size, it must be able to render as much content that fits 
   in it, and let another box continue.
-- It may need ability to change appearance of content when it flows 
   through it (such as provide background or change text properties)
-- It may need OM to determine what portion of content exactly is in it.

Imagine for a moment that we are free to create HTML element or CSS properties at will, we just need to decide what we want. What would it be?

Why not something like this?

A)  <story src="url" flow="flowname">
        fallback content that is used as source if there is no 'src'
        property or if source url fails to load

    Very similar to <iframe> or <object> (and takes advantage of iframe 
    security boundaries), but is never rendered itself.
B)  <page flow="flowname" />

    "page" as a virtual page of content that is flown through these boxes.

    Kind of like iframe for layout -- content has no effect on its 
    container size. It cannot have content of its own.
    Content shown in the box is part of a story, possibly continued 
    from another box.

HTML is about semantic elements, and (A) sounds pretty semantic. It is pure data. Ought to be an element. (B) is right on the boundary between content and view -- it shows content from elsewhere. Which is about as far as it gets from a style -- its own content is not getting styled, it is getting dumped...

OK, back to reality. I asked around, and I hear it is difficult and generally not a good idea to add elements to HTML. I am not sure I agree with reasoning, but let's suppose a new element is not an option. What else?

Let's look for second best.

(A) <object> looks the closest. It has fallback to inline content. And it has not default rendering. Would be like this:

	<object data="foo.html" flow="flowname">

Not very intuitive though... <iframe>, <link> are other options. <div> is possible but not great, as it doesn't naturally redirect to a file.

(B) This is not looking good. Basically the choice is between
	<iframe> - because it already ignores its content. But it has "src" 
                 which is supposed to be loaded - and ignored too???
	<div> (or any other non-replaced element) -  no "src" to worry about,
                 but we'll have to discard the content which is unusual.
      <embed> - another element with no content, but very non-intuitive.
      ::slot - a pseudo-element created from CSS, no inline content to ignore. 
                 but also no OM (as it is not an element)

Given the choices, I think <iframe> as flow source and <div> as flow container are lesser evil, but I still believe definition for linked flow containers belongs to HTML - in a perfect world.

(attached: a simple example with a few syntax options, from new element to ::slot)

What do you think?

Received on Sunday, 3 April 2011 10:07:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC